GraphQLのfragment ● GraphQLはfragmentを使うと、必要なデータを 宣言的に定義することができる ● 👉ではInterface Memberの中から必要なデータを WebAccountとして宣言している ○ 全MemberはgithubIDを取得できる ○ … on 型名でInterfaceの具体的な型の場合取得するデータを 宣言することができる ■ Type DesignerならAdobe IDが取得できる fragment WebAccount on Member { id githubID ... on Designer { adobeID } }
); }; fragment GitHubName on Member { id githubID } 👆コンポーネント定義側 fragment WebAccount on Member { id githubID ... on Designer { adobeID } } … fragment名で、fragmentに定義され ているデータを持ってくることができる
); }; fragment GitHubName on Member { id githubID } 👆コンポーネント定義側 fragment WebAccount on Member { id githubID ... on Designer { adobeID } } コンポーネントに必要な fragmentを引い ているので、そのままオブジェクトを渡す ことができる
); }; fragment GitHubName on Member { id githubID } 👆コンポーネント定義側 fragment WebAccount on Member { id githubID ... on Designer { adobeID } } Interfaceが 特定の型だったときのみ 持ってくるデータが書ける … on Designer と対応した記述ができる (designerだったらAdobe IDを表示する)
データベース上の限定近況ノートの扱い ● データベース上では限定近況ノートかそうでないかは、近況ノートのテーブルのフラ グで管理している ○ 実際にこの近況ノートが読めるかどうかはバックエンドで管理している ● データベースのスキーマとGraphQLのスキーマを 一致させる目線に立つと、1つの型で表現する必要 性が出てくる id title body is_limited author_account_id
このUIを実現しようとするとエラーが ● フロントこのUIを満たすfragmentを定義したところバチバチに怒られる ○ 同じbodyというフィールドなのに型が String!とStringで違うから無理!!! ○ ○ ○ ● Interfaceの実装の型において同名のフィールドは同じ型の方が望ましそう ○ 読めない限定近況ノートの場合は bodyがnullの可能性がある ○ 今回のスキーマのままいくと、普通の近況ノートでも bodyをString!にしなければならない ● 今回は明らかにこのスキーマだと作りたいUIが表現できないので再考 GraphQLDocumentError: Fields "body" conflict because they return conflicting types "String!" and "String". Use different aliases on the fields to fetch both if this was intentional.
anatofuz
ytaisei
line_developers
yokawasa
linedevth
miyake
ryomaru0825
autifyhq
dach
hamadakoji
rigolon
nrryuya
sstephenson
kastner
malarkey
bkeepers
3n
morganepeng
wjessup
chrislema
dotmariusz
denniskardys
yeseniaperezcruz
edds