コンポーネントの分類について考えたことをまとめた
どのようにコンポーネントを分類していくか 個々のコンポーネントがが単一の責任のみ負っている状態であれば、コードの見通しも良くなる上、後々のメンテナンスも容易です。 まずは「複数の関心ごとを１つにまとめない」という原則（単一責任の原則）から分類の指針を考えていきます。 フロントエンドにおける関心ごとですが、大別すると APIとの接続 View（表示とイベント実行） 状態管理 以上３つに集約されるのではないでしょうか。 では、これらの関心ごとをどの様に切り分けていけば良いのか考えていきます。 APIとの接続 まずはAPIとの通信ですが、こちらはコンポーネントの外で管理した方が良いと考えています。 各コンポーネントに通信に関わる処理がベタ書きされている状態だと、エンドポイントの変更等に弱くなり、通信処理の再利用も面倒です。 それに、「フロントの状態管理 / 表示」と「外部との接続」はそれぞれ別種
Storybook First な開発のススメ
Storybook first な開発とは Storybook での呼び出され方を意識しながらアプリケーションコードを書くことをそのように呼んでいます。 道具に設計がひきづられるのはアンチパターンと言われそうな気もするのですが、コンポーネントのカタログを整備していくことは、コンポーネントが良い感じに再利用可能な形で分離できるということでもあり、やっていくとむしろ正道に近づいていくと思います。 Storybook First のコンポーネント設計や型定義をすると、パーツに限らず Storybook でカバーできる範囲が広がり、ページそのもののサンドボックスを作れます。 そして API がない状態でもデータを使って開発ができたり、特定のスナップショットの再現やタイムトラベルに近いことも可能になるというメリットがあります。 つまり、ただのコンポーネントカタログとしてではなく、開発のためのサンドボ
react-redux hooks 時代のContainerコンポーネント - Qiita
先日 react-redux の v7.1 の stable release で hooks に対応したAPIが入り界隈で話題になりましたね。(追加されたAPIの詳しい解説はこちら https://react-redux.js.org/api/hooks) 結構コンポーネント内からお手軽に参照できる感動を伝えている情報が多いのですが(実際私も感動の嵐です)、ここで改めて「なんで Container コンポーネントって必要なんだっけ？」と「hooks APIではどうやって Container コンポーネントを書くのか」を考えていきます。 なぜ hooks API になった今でも Container コンポーネントが必要なのか 始めにここで言う "Container コンポーネント" は 「Redux の Store から値を注入するためのもの(あとdispatch 関数)」という狭義の意味で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
