大幅リニューアルがありました。コンポーネント設計について記載します。親子関係以外(兄弟)のやり取り親が状態を持ち、子の入力を親へ反映させるシンプルなパターン(モデルの型がプリミティブな場合)値がオブジェクトの場合コンポーネントが入れ子の場合ルーター(URL)で画面の状態を維持まとめはじめにリニューアル前のコンポーネント設計は開発者依存でカオスな状態でした。可読性、保守性が低く、バグがあった際にどのコンポーネントが原因なのか調査が難しい状態でした。この反省を踏まえ、リニューアル時はコンポーネントをどう設計するかを規約として定義しました。導入してみましたが、途中でやめました。やめた理由は以下のとおりです。開発の過程で、コンポーネントを見た目で分離するのでなく、役割で分離するほうが重要と感じたためです。どのコンポーネントにどこまでの役割をもたせるか定義されていません。だらけになるため導入のメリットないと感じました。いうわけで、新しくコンポーネント設計の規約を定義しましたので、これについて記載していきます。規約は今後も変更する可能性があります。利用前提としています。デコレータで定義しています。階層で定義することとしました。コンポーネント以下のようなイメージで親子関係を持ちます。コンポーネント画面の複雑度に応じて階層は増減しても良いことにしています。コンポーネント次に各コンポーネントの役割を記載していきます。配置される最上位のコンポーネントです。ルーターのルートになります。内に配置されるコンポーネントです。