PROMARI JOURNAL

iframe から、丸型の共有ボタンと「いいね」へ。Promari SNS Share を公開しました。

作成: / 公開: / 内容更新:

執筆:tamito0201 / 掲載・運営:プロマリ

丸い共有ボタンの設計を、用語のポップアップと身近なたとえでたどります。表示・保存・計測・配信の内容を省略せず、四層の責任と設計判断を詳しく解説。全5ページ、連載予定は16章。

PASS IT ON

ひとつの発見を、次の会話へ。

丸いボタンの裏側を、設計・実装・運用から掘る

ここまでお付き合いいただき、ありがとうございます。最後に、前のページの終わりでお話しした連載の目次をご紹介します。共有先を一つ増やしたら、どこまで変更が広がるのか。いいねを再送しても、票と履歴を揃えられるのか。下の16章では、実装の制約と別案のトレードオフを、コードと検証結果で比べる予定です。いま動いている仕組みを出発点に、改善案も扱います。1章3〜4回を目安に、保存API・計測・配布は5回。気になるところから、のぞいてみてくださいね。

PROMARI JOURNAL · SERIES

連載の目次 全16章 / 66回の予定

  1. 第1章丸いボタンから責務を切る――変更理由と設計判断
    1. 1.1共有・保存・計測は、なぜ同じ責務にしないのか
    2. 1.2共有先が増えても触らないコードを決める
    3. 1.3ADRに残すのは結論より、捨てた案と制約
  2. 第2章SOLIDは変更に耐えるか――共有先の追加でインターフェースを試す
    1. 2.1SRP――一つの共有先の定義は、一つの理由で変わるか
    2. 2.2OCP――共有先を一つ足したときの差分を追う
    3. 2.3LSP――Copyに「開くURL」を要求すると何が壊れるか
    4. 2.4ISP――コピーの代役に、いいねの保存まで求めない
    5. 2.5DIP――ブラウザの機能を、ポートの向こうへ置く
    6. 2.6共有先の登録――明示登録から自動探索へ
  3. 第3章ブラウザ抜きで動かす――Ports and Adaptersの境界
    1. 3.1値オブジェクト――共有URLを状態変更から守る
    2. 3.2ユースケース――操作の判断と副作用を引き離す
    3. 3.3ポートのインターフェース――APIの形だけでなく失敗を揃える
    4. 3.4Composition RootとDIコンテナ――具体実装をどこで選ぶか
  4. 第4章型が通るのに壊れる――TypeScriptの境界を詰める
    1. 4.1strictとnull――状態が未確定の時間を型へ持ち込む
    2. 4.2Discriminated Unionとnever――分岐漏れを検出する
    3. 4.3Mapped Types――設定キーと値の対応を崩さない
    4. 4.4unknownから検証する――JSONにasだけでは足りない
  5. 第5章型で約束を磨く――不変性とURLエンコードの落とし穴
    1. 5.1凍結・readonly・選択肢――変更を許す範囲を決める
    2. 5.2RFC 3986――二重エンコードとHTMLエスケープを分ける
    3. 5.3データファイルからTypeScriptへ――共有先の定義の二重管理をやめる
  6. 第6章生成したのに古い――TOMLから配布物までの整合性
    1. 6.1設定の正本――共有先の定義とサイト設定を分担する
    2. 6.2スキーマ検証――未知キーを、生成時は止め、表示時は外して知らせる
    3. 6.3Deep Merge――上書きにしか無いキーと、配列の上書き順
    4. 6.4決定的な生成――再生成差分でドリフトを捕まえる
  7. 第7章タグ一つで持ち運ぶ――Web Componentsの公開インターフェース
    1. 7.1whenDefined――要素の登録とデータの準備を分ける
    2. 7.2属性・メソッド・イベント――不正な値の扱いと、互換性の対象
    3. 7.3Shadow DOM――retargetingとcomposedの経路を追う
    4. 7.4再接続と再描画――イベントリスナーを増殖させない
  8. 第8章awaitの先は成功とは限らない――共有APIの非同期処理
    1. 8.1Promiseの拒否――エラーを握り潰すと何が観測できないか
    2. 8.2Clipboard API――成功表示と手動コピーの境界
    3. 8.3Web Share――ユーザー操作・キャンセル・フォールバック
    4. 8.4requestAnimationFrame――スクロール監視と描画を分ける
  9. 第9章見えているだけでは使えない――操作と描画のインターフェース
    1. 9.1aria-pressedとaria-live――状態同期と通知の重複を分ける
    2. 9.2フォーカス管理――Escapeの後、どこへ戻すか
    3. 9.3SVGと動的描画――信頼できる定義と外部入力を分ける
  10. 第10章いいねはカウンターではない――非同期UIを状態機械にする
    1. 10.1未取得・保存中・失敗――booleanの組み合わせを減らす
    2. 10.2setLikeState――希望状態・確定状態・未取得(null)の境界
    3. 10.3冒頭と末尾の同期――連打と遅延応答をどう扱うか
    4. 10.4楽観的更新か確定後更新か――失敗時の戻し方を比べる
  11. 第11章WordPressへ閉じ込めない――テーマと部品の接続設計
    1. 11.1actionとfilter――フックが呼ばれる文脈を追う
    2. 11.2共有欄の二重表示――配置の所有者を一つにする
    3. 11.3会員・記事・ページ――接続側へ残すデータと責任
    4. 11.4分割記事のコメント――ページ別表示と最終ページの集約
  12. 第12章二重に増えないAPIへ――会員・匿名識別と冪等性
    1. 12.1GETとPOST――取得で票を移さないHTTPのインターフェース
    2. 12.2会員IDと署名Cookie――ログイン前後の票をどう扱うか
    3. 12.3nonceは認可ではない――Origin・Host・公開範囲・要求の検証
    4. 12.4GET_LOCKとトランザクション――票と操作履歴を揃える
    5. 12.5レート制限と集計――現在の票・操作回数・実人数の違い
  13. 第13章そのクリック、何の数字?――イベントと同意管理
    1. 13.1操作・成功・投稿完了――計測できる事実を限定する
    2. 13.2CustomEvent――DOMの構造を計測APIにしない
    3. 13.3同意前の保留と拒否時の破棄――GA4送信の境界
    4. 13.4UTMとイベント――流入数と共有操作数が一致しない理由
    5. 13.5イベント名を変えても計測を止めない――送る側と受け取る側を同じ設定から読む
  14. 第14章緑のテストを疑う――インターフェース・競合・ブラウザを検証する
    1. 14.1URL生成と保存API――失敗を切り分けるテストの層
    2. 14.2テストダブル――本番アダプターとのインターフェースのずれを防ぐ
    3. 14.3DockerとPlaywright――会員操作とページ間集約を通す
    4. 14.4再送・失敗・後始末――状態を残さず再現する
  15. 第15章同じ版を本当に配れるか――モノレポからCDNまで
    1. 15.1pnpm workspaceから離れる――部品ごとのロックファイルでリリース単位を分ける
    2. 15.2型検査とバンドル――build成功が保証しないこと
    3. 15.3SemVerとタグ――属性やイベントの変更も公開APIとして扱う
    4. 15.4バージョン固定・SRI・CORS――URLと内容をセットで検証する
    5. 15.5署名とSBOM――配布物を受け取る側が、手元で照合できるようにする
  16. 第16章配備成功の、その先へ――本番との差分を閉じる
    1. 16.1GitHub Actions――テスト失敗と未実行を区別する
    2. 16.2set -eだけに頼らない――シェルの終了状態を検証する
    3. 16.3SSHとハッシュ照合――送る差分と戻せる範囲を決める
    4. 16.4DB・画像・キャッシュ――HTTP 200の先を読み戻す
  17. 番外編連載の合間に、共有欄そのものを育てる
    1. 番外1そういえば、書く場所へは共有できなかった――Qiita・Zenn・note・Medium・アメブロへの共有を足す

一つの問いを、一回ずつ。回数は内容に合わせて調整します。

プロマリでは、Web制作とアクセス解析の導入、それらを運用できる人材の育成に取り組んでいます。自社サイトの共有や計測の仕組みを見直したい方は、お気軽にご相談ください。

Web制作・計測・人材育成のご相談はこちら

COMMENTS
コメント…

この記事全体の感想・質問・設計へのコメント

PASS IT ON

この気づきを、誰かにも。

この記事を書いた人

Takaomi Murasaki

Promari SNS Shareの開発を通して、Webの仕組みや設計の選び方を紹介しています。動く実装と、その判断に至るまでを記事に残しています。

公開記事 11 件

プロフィールを見る
THANK YOU FOR READING.すべての記事へ ↗

FROM INSIGHT TO IMPACT

「できたらいいな」を、
動く仕組みに。

記事で見つけたヒントを、あなたの事業へ。
新しいサービスも、手間のかかる業務も。
いまの課題から、つくるべきものを一緒に考えます。

開発・AI・研修の実績を見る

まだ、仕様書はいりません。

「何から始める?」から、ご一緒に。

課題がまとまっていなくても大丈夫。テーマを選ぶと相談文をご用意します。
連絡先の必須入力は、お名前とメールアドレスだけ。

まずは課題の整理から相談する

ご相談後の流れ

  1. 01 内容を確認
  2. 02 メールでご連絡
  3. 03 課題・進め方をご相談
送信だけで契約やお申込みが確定することはありません。