0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

urqlとは:React向けの軽量で柔軟なGraphQLクライアントライブラリ
その中でもcache-updatesについてのアウトプットです

大事なのは__typename

ミューテーションで更新があった場合、__typenameを理解して
勝手にキャッシュを更新してくれます。

ですので、更新などのコマンドが操作された時に
BFFからIDのみを返すのではなくて__typenameが入ったスキーマの形を返してあげると、
データ更新後の取得をフロントが気にする必要がなくなります。

BFF内で更新+取得を行い該当の__typenameの型で返してあげることを意識するということです。
これができるとフロントで無駄なstate管理をする機会が減り、
謎のコンポーネント間のバケツリレーをする必要がなくなります。

失敗の思い出

BFFのservice内でコマンドのAPIを作成しているときに、

コマンドのAPIはコマンドしか呼ばずにIDだけを返そう。
画面更新するまでに即時反映しないデータはその時だけuseStateでバケツリレーして
useEffectで更新してあげよう。

という取り決めをしたことがありました。

そしたらどうでしょう。
遠くから更新の処理でやってきたstateが下から上まで通って渡らなくてはいけなくなったり
一番上のtemplateで多くのstateを持たなくてはいけなくなるなど
保守がとんでもなく大変なことになりました。
これはなぜスキーマが__typenameを持っているのかなどキャッシュについて理解が足りていなかったことが問題だったなと今では思います。
今でもその保守に追われております

さいごに

せっかくGraphQLurqlを採用しているのにキャッシュの機構を理解しないのは勿体無いなと思い
改めてドキュメントを読んでいるところです。
ここら辺は相手に説明できるくらいである必要があると感じているのでしっかり知識として取り入れたいです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?