Documentation
Basics
Querying from the client
Best practices

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.