From 589680f3237d760270912b0b370796a512d60d40 Mon Sep 17 00:00:00 2001 From: Ben Kraft Date: Tue, 11 May 2021 14:32:11 -0700 Subject: [PATCH] Notes from meeting about content-library In general it seems like they are happy with the potential future fragments plan! --- DESIGN.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DESIGN.md b/DESIGN.md index c665bea..f6f0497 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -151,7 +151,7 @@ Optionally, we might define a getter-method `GetB() string` on `T` and `U`, and ```go type F interface { isF(); GetC() string; GetD() string } ``` -so that if you want to use the same fragment `f` to share code in several places, you can do that, because all of the relevant types will implement `F`. To do that we'll have to have the type-names for fragment fields rooted at the fragment rather than at the query, which is probably preferable anyway since they are guaranteed to be the same for all spreads of the fragment. +so that if you want to use the same fragment `f` to share code in several places, you can do that, because all of the relevant types will implement `F`. To do that we'll have to have the type-names for fragment fields rooted at the fragment rather than at the query, which is probably preferable anyway since they are guaranteed to be the same for all spreads of the fragment. (Or we can just do the methods, and let you define the interface, although you still have to root the type-names for the same reason.) Another natural option, which looks more like the way `shurcooL/graphql` does things, is to generate a type for each fragment, and only fill in the relevant ones: ```go