最小構成のブロックが動くようになった今、Day3 ではさらに一歩踏み込んで、Gutenbergブロックの設計の本質を理解します。見た目ではなく、状態（attributes）と表示（render）の分離という概念がブロック設計の核です。
なぜ「設計」から考えるのか
ブロックをただ作るだけであれば、コードを書いてしまえば動きます。しかし、本当に強いブロックを作るには、どうデータが動いているかを理解する必要があります。これは将来、OGP取得や外部API連携、パフォーマンス改善などを行うときに不可欠な思考です。
ブロックはどのように保存されるか？
WordPressの投稿本文に保存されるのは、HTMLではありません。dynamic ブロックの場合、投稿内に保存されるのは JSON 形式で、attributes のデータです。
<!-- wp:foblocks/test-block {"message":"こんにちは"} /-->この JSON は WordPress が内部的に解釈して、編集画面や表示画面に反映します。HTML をそのまま保存しているわけではなく、設計データとして保存
edit.js の役割：UI と 状態の関係
edit.js は、編集画面でユーザーとやり取りする部分です。ここでは ユーザーの入力を受け取り、attributes に保存するという役割を担います。
- 編集用フォームを表示
- ユーザー入力を受け取る
- setAttributes を使って状態を更新
ここで更新された attributes は、投稿に保存され、“状態”として保持されます。UI は見た目ですが、attributes はその UI の背後で動いている 状態データなのです。
attributes とは「ブロックの状態」
attributes は、ブロックが“覚えておく必要のある値”を定義する場所です。URL のようなユーザー入力や、取得したデータなどを保存します。
例えば、リンクカードブロックでは次のような設計になります：
- url：リンク先URL
- title：OGPタイトル（取得して保存）
- image：OGP画像URL（取得して保存）
- label：カードに表示するラベル
属性ごとに“性質”が異なるため、それぞれの扱い方を設計で決めておきます。
render.php の役割：表示の制御
render.php はフロントエンド出力を担当します。保存された attributes を受け取り、HTML を生成する役割です。ここではデータを見て、「どう見せるか」「どの要素を出すか」を決定します。
状態 (attributes) は render.php に渡されるため、render.php 側でデータの存在チェックや fallback 処理をすることで、表示の安定性を担保できます。
fallback （フォールバック）とは、本来表示したいデータが取得できなかった場合に、代わりに表示する代替手段のことです。
edit と render を分離する設計のメリット
edit と render を分離することで、次のようなメリットがあります：
- 表示する時の負荷が減る
- 保存された値を使い回せる
- 表示ロジックを変更してもデータに影響がない
- 将来の拡張（OGP取得など）をしやすい
この設計思想が理解できれば、ブロック開発の“地平が一段変わる”はずです。
データの流れを図で整理
ブロックでデータがどう動いているかを、処理順で示すと以下のようになります。
ユーザーが入力（UI）
↓
edit.js が setAttributes で状態更新
↓
attributes に保存（JSON）
↓
render.php で HTML 生成
↓
フロント画面に表示この流れがわかっていると、「どこで何をすべきか」が一目で理解できます。
まとめ
Day3では、「見た目」ではなく「設計」からブロック開発を整理しました。attributes はブロックの状態を保存する場所であり、render.php はその状態をもとに HTML を出力します。
edit と render の分離、データ設計の意図を理解することで、今後の拡張やパフォーマンス改善にも対応できるブロック設計ができるようになります。
次回はこの設計をベースに、より実用的な入力と取得処理に挑戦していきます。