コンポーネントの分類について考えたことをまとめた
どのようにコンポーネントを分類していくか 個々のコンポーネントがが単一の責任のみ負っている状態であれば、コードの見通しも良くなる上、後々のメンテナンスも容易です。 まずは「複数の関心ごとを１つにまとめない」という原則（単一責任の原則）から分類の指針を考えていきます。 フロントエンドにおける関心ごとですが、大別すると APIとの接続 View（表示とイベント実行） 状態管理 以上３つに集約されるのではないでしょうか。 では、これらの関心ごとをどの様に切り分けていけば良いのか考えていきます。 APIとの接続 まずはAPIとの通信ですが、こちらはコンポーネントの外で管理した方が良いと考えています。 各コンポーネントに通信に関わる処理がベタ書きされている状態だと、エンドポイントの変更等に弱くなり、通信処理の再利用も面倒です。 それに、「フロントの状態管理 / 表示」と「外部との接続」はそれぞれ別種
useEncapsulation | Kyle Shevlin
Update November 22nd, 2021: I added a recording of my CascadiaJS on this topic to the end of this post. Enjoy! Recently, I shared this tweet: 🔥 take I haven't fully thought through incoming: Every use of useEffect should be in a custom hook with a damn good name. It's frequently difficult to read & comprehend intention of the code when effects are strewn about. Better to encapsulate and provide c
ベストな手法は？ Reactのステート管理方法まとめ - ICS MEDIA
Reactでのシングルページアプリケーションを作成していると、必ず意識しなくてはいけないのが状態管理です。Hooks APIの登場により、アプリケーションの状態管理方法にも選択肢が増えてきました。2023年のReactアプリケーションの状態管理方法はどのような選択肢が考えられるでしょうか？ 状態管理の選択肢 Reactの状態管理として本記事でには紹介している手法は下記の4通りになります。 ローカルステート（useState、useReducer）での管理 Hooks APIのuseReducer、useContextを使った管理 Reduxによる管理 Recoilによる管理 状態管理フレームワークは他にも選択肢がありますが、Reduxを紹介します。理由は、候補として挙がるライブラリの中でもっともシェア数が多く、知名度が高いためです。 下図は、主要なReact状態管理フレームワークのダウンロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hooks時代の設計の話 #agrinoteinside
