Day 7: Week 1 まとめ - 構造パスの基礎を振り返る

この記事は「構造パスで作るシンプルなフロントエンドフレームワーク（Structive）」Advent Calendarの7日目です。
Structiveについて詳しくはこちらより

Week 1 で学んだこと

Day 1: 課題と解決策

従来のフレームワークの課題：ボイラープレート、複雑な中間層、仮想DOMのコスト

構造パスの解決策：UIと状態が同じ構造パスを共有

class State { user = { name: "Alice" }; }

<p>{{ user.name }}</p>

Day 2: 構造パスの基本

データへの「住所」 = 構造パス

"user.profile.name"  // ドット記法
"items.*.price"      // ワイルドカード（配列の全要素）

Day 3: UIと状態の思想

核心: UIと状態は同じデータの異なる表出

3つの原則:

1. 同じ構造の原則
2. 単一の真実の原則（Single Source of Truth）
3. 直接操作の原則

Day 4: ボイラープレートの排除

不要になったもの：useState、setter関数、イベントハンドラのラッパー

export default class {
  count = 0;
  increment() { this.count += 1; }  // これだけ
}

Day 5: リアクティビティの仕組み

Proxy + 構造パスでピンポイント更新

this["product.name"] = "New";
// → Proxyが検知 → {{ product.name }} だけ更新

仮想DOM不要：差分計算なし、直接DOM更新

Day 6: カウンターアプリ実践

4つの機能（カウント、ステップ、リセット、履歴）を実装

• コード量: 約1/3に削減
• ボイラープレート: ゼロ
• 配列の扱い: concatやtoSplicedで新配列を代入

核心概念の整理

概念	説明	例
構造パス	データの位置を文字列で表現	"user.profile.name"
ワイルドカード	配列の全要素を抽象化	"items.*.price"
1対1対応	UIと状態が構造パスで結合	{{ count }} ↔ state.count
Proxy検知	状態変更を自動検知	this.count = 5 → UI更新
ピンポイント更新	変更箇所だけをDOM更新	仮想DOM不要

Week 1 の成果

✅ 構造パスの基本概念を理解
✅ UIと状態の関係を理解
✅ ボイラープレート不要の仕組みを理解
✅ Proxyによるリアクティビティを理解
✅ カウンターアプリを実装

Week 2 への準備

次週（Day 8〜14）はコア機能編：

• Day 8: forブロックとループコンテキスト
• Day 9: ifブロックで条件付きレンダリング
• Day 10: 属性バインディングとイベントハンドラ
• Day 11: 派生状態（getter）
• Day 12: パイプフィルター
• Day 13: Todoアプリ実践
• Day 14: Week 2 まとめ

より複雑な機能を学び、実用的なアプリケーションを作っていきます。

---

次回: Day 8「forブロックとループコンテキストの仕組み」

Week 1 お疲れさまでした！分からないことがあればコメントで質問してください。