Best practices
There are some best practices we strongly believe in while developing with fuse
.
Don't interpolate arguments
When we are working with field-arguments
it's important to either write them as a literal value i.e.
query {
users(limit: 10) {
nodes {
id
name
}
}
}
or interpolate them as variables
query ($limit: Int!) {
users(limit: $limit) {
nodes {
id
name
}
}
}
String concatenation like limit: ${myJsLimitValue}
is discouraged!
Fragment naming
We suggest that you follow a naming pattern with fragments to make them both easy to discover as well as easy to understand to what component they relate.
When we name our fragments like Filename_TypeFields
we can easily see which component the fragment
relates to when it's being spread into a query. This allows
us to also easily know that we can remove the fragment once we remove the component.
An example of this could be the following, when we have an Author.ts
file we would define a fragment
that looks like
fragment Author_UserFields on User {
id
name
avaatarUrl
}
Now when we spread it in our Blog
page we can easily see that it relates to the Author
component, when we
inspect the GraphQL document being sent to the server
we can also derive that this is meant for that component.
useFragment
and FragmentType
You'll see that we use this useFragment
function in our components that have a fragment describing their
data-requirements, this helper ensures that we remove any extraneous fields and type the output correctly.
Another thing worth noting is how we type the props
, we use this FragmentType
helper which ensures that
the parent-component uses the fragment and passes that into props, this means that if the parent-component
would define all the fields of the fragment manually and not spread it that we would show a warning.
Note that even though this function is called useFragment
, it is not a React hook and you need to use it in server components too.
Top-level queries
One of the benefits that comes with describing the data you need is that you perform 1 request and get 1 response, no waterfall where you need to wait for the list and then perform a whole set of other requests to enrich that data, ... We wrangle the data once, with this comes our sugestion to aggregate the data you need by means of your fragments at the page-level, in doing so you resolve all data in a single request.
With modals/... that pop up you can do one-off requests later when you need the data but not having a waterfall of loading spinners because you are navigating around feels both more performant and more user-friendly.