Comments (4)
Great questions.
But imagine if one day it is necessary to add new fields which is ManualCollection specific.
The solution depends on how generic you can make these fields in my opinion. As you mentioned, CollectionRule
was made more generic and the empty list is a fine trade-off which still makes some semantic sense.
A decision like this is more of a spectrum, not really a simple binary choice. In our case (and the tutorial's), there aren't enough reasons to use an interface. But if you start adding more differences, then maybe an interface does make more sense. In the end it's your API and up to you anyway 😄
from graphql-design-tutorial.
Another solution (and one that we use internally in a few places - we should find a way to work it into the tutorial somehow) is to use a union on the differing fields. Something like:
type Collection {
...
specificFieldSet: SpecificFieldSet!
}
union SpecificFieldSet = CustomCollectionFields | Collection2Fields | Collection3Fields
The advantage of this is that often you can find a better semantic name than SpecificFieldSet
. For example, say that the collections were different specifically in how products were sorted (and these specific field sets implemented different approaches to that). Then you could call the field and union productSortDetails: ProductSortDetails!
and it's much more obvious what it does and why.
Internally we call this concept "pushdown polymorphism" because you're pushing the polymorphism (which is technically on the collection) down into the specific semantic dimension of difference.
from graphql-design-tutorial.
The solution depends on how generic you can make these fields in my opinion.
Great point! I believe that ManualCollectionFiledSet
is a generic field, if it is null, it means that these fields are not applicable for a AutomaticCollection
, so still have some semantic meaning. It also follows the rule 6:
Rule 6: Group closely-related fields together into subobjects.
So I followed this principle, but I don't know if it is a good practice.
Because, imagine if there are 10 types of collection, and each type has a set of specific fields and I would like to query all these specific fields. In this case, what I need to do is:
query {
collections {
fieldSet1 {
...
}
fieldSet2 {
...
}
fieldSet3 {
...
}
fieldSet4 {
...
}
fieldSet5 {
...
}
fieldSet6 {
...
}
...
}
}
These would lead a lot of null values, each collection would have 9 fieldSets null and 1 fieldSet with some value. Quite bad.
A decision like this is more of a spectrum, not really a simple binary choice.
Yeah, but it would be awesome to have some guide for this situation, because people may understand that interfaces are not necessary and specializations are all detail implementation.
from graphql-design-tutorial.
Nice point!
I believe that for my situation, some specialization is required. So I will go with interfaces or unions.
There are some awesome articles talking about these topics:
Maybe these tips could be added to the tutorial somehow.
Thanks for the discussion, it was really helpful and constructive! Closing this issue.
from graphql-design-tutorial.
Related Issues (13)
- Translation HOT 1
- Defaulting to semantic nullability HOT 3
- Grouping GraphQL Mutations is Supported HOT 2
- Missing code segment HOT 2
- example implementation
- In GraphQL data modeling, you should think of your data as a graph, not as tables HOT 1
- Naming of mutations and rule 17 HOT 2
- クライアントをGraphQLクライアントとするのはいかがでしょうか? HOT 1
- Putting data on edges (or not) HOT 3
- ㄴㅇㄴ
- When designing GraphQL, you should think of your data as a Graph instead of Tables HOT 1
- userErrors in Payload interface? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from graphql-design-tutorial.