🎃

モダンWebフロント個人的ピックアップ #1

2021/04/08に公開

GraphQL

Next.js

React

tech

GraphQLが解決する問題とその先のユースケース

その後生まれて来ているユースケース
GraphQL導入の検討

要約

GraphQLが解決した問題

API インターフェース: APIインターフェースとしてGraphQLを導入することによってフロントとバックエンドが柔軟に実装・変更が可能。
クライアントリソースの軽減: 状態管理をGraphQLクライアントが自動化してくれるため、クラサバ間のキャッシュ・状態管理にReduxを使う必要がなくなった（クライアント側で発生する状態管理にはReduxを使うケースはある）

利用の中で生まれて来たユースケース

マルチクライアント: 異種クライアントやユーザー毎のUIを作りやすい。
API層のAnti-Corruption(腐敗対策) Layer: APIインターフェースとしてGraphQLを導入することによってインクリメンタルな変更・改善が可能。
Realtime API with Subscription: Subscriptionで状態をサーバープッシュで受け取ることが可能。
巨人の肩に乗る: 新しい技術は既存技術の課題解決をしている可能性が高いので、新しい技術を率先して使う。

GraphQLの導入するタイミング

GraphQLが向いているケース: 変化・進化し続けるアプリケーション。複雑性の高いアプリケーション。
クラサバ間での状態同期が必要かどうか
複数種類のクライアントがある
Microservicesを採用している
大規模なアーキテクチャ変更が必要

感想

巨人の肩に乗る気持ちでGraphQLを使っていたので非常に勉強になりました。

感想というより疑問点ですが、「GraphQLが解決した」というより、「BFFによって解決できる」の方がしっくりくる...?と思うところがありました。例えば「API インターフェース」などです。
アーキテクチャなどまだまだ詳しくないので詳しい方是非教えていただけるとありがたいです🙏（そもそも僕の解釈が間違っていたらご指摘頂けると嬉しいです）

Next.jsのISRで動的コンテンツをキャッシュするときの戦略

要約

getStaticPropsの返り値にrevalidateを指定する。
revalidate: 10と設定した場合、10秒間はそのキャッシュを返す。10秒経過後の最初のリクエスト時にキャッシュを更新する。しかし、10秒以降の最初のリクエストに対しては以前のキャッシュを返す。
posts/[id]などの動的ルーティングの場合は、getStaticPathsも合わせて指定する必要がある。
fallback: 'blocking'を指定するとキャッシュがまだ作られていないときはSSRのようなことを行える。
強整合性が求められるページにISRは向いていない
ブラウザにマウントされてから最新のデータを読み込み直すことで、ISRをしながら最新のデータを表示することができる。

Next.jsでApolloクライアントを使い始める

要約

SSGまたはISR、SSRを使うときはHooksを使わずに直接Apolloクライアントをインポートし、それぞれgetStaticProps, getServerSideProps内でフェッチする。

React Hooksでテストをゴリゴリ書きたい - react-reduxやaxiosが使われているような場合もゴリゴリテストを書きたい

最近フロントエンドのTDDに興味を持って挑戦中で、Hooksのテストを書く際に見つけました。なぜTDDに興味を持っているのかというと、設計向上による保守性の向上と、適切なテストによるサービスの信頼性の向上です。今まではテストへの挑戦を拒んできましたが、一定期間何か発見があるまでどんどんテストを書いてみようと思います。

なんとなくでやらないReact.memo戦略

要約

基本的にはstateの持ち方やコンポーネントの分割を適切に行うことで再レンダリングを防げる。
現実問題、たくさんのstateを持つコンポーネントが出てくる。
その時は
- useCallbackで不必要に関数が新しく作り直されるのを防ぐ(これをしないと、callback関数はpropsで渡すことになるので、無駄に再レンダリングされることにつながる)
- memoでpropsが変化していないのに、不必要に再レンダリングされるのを防ぐ。