8/6/2023 0 Comments Graphql nested fragments![]() So, since we added the RelatedBooks node with an argument, we now need to define the same argument in the users' list query, otherwise, it'll break your GraphQL request. It works great! But do you remember that we have this BookFragment spread in the users' list? Taking our previous case as an example let's say in our books' list we want to display a list of related books, to do so we create a fragment and use an argument to order the related books by name, so it'll look something like this: Nested fragments and argument dependenciesĪnother issue of nested fragments is the argument dependencies. Even if your fragment looks big (too many lines), it's better to have a well-controlled fragment in a single component, than facing over fetching or data dependency issues. Instead of using nested fragments, I'd suggest keeping your fragments as flatten as possible. You'll definitely have headaches when start to face performance issues. This is quite a simple example but think about it in a large and complex application. The same applies if after a few months in the project you no longer need some data in the users' list, but you do in the books' list, you might end removing some data from the AuthorFragment to fix the users' list and then introduce errors to the books' list. If we don't need the author data in the user list since we're spreading the AuthorFragment in the BookFragment, and the BookFragment in the UserFragment, when you load the user list your query will fetch more data than your component needs, and so you'll fall into the over fetching issues. We can create an AuthorFragment and add it to the BookFragment: We would need a query like this:Ĭool! Now let's say we want to display the author data in the books' list. Let's say that we need to display to the users the list of the books available in our application to be selected. So we create a query in our GraphQL using a UserFragment and a BookFragment. Then, we want to display the list of users and the books they read. Let's say we have an application where the user selects the latest books he/she read. ![]() In the previous topic, we talked about the issue of reusing the fragments and over fetching issues. It also helps with the scalability and maintainability of the project. You might repeat yourself more often, but you'll never face over fetch, under fetch, or performance issues. So each component in your tree is responsible for defining the fragment with all the data it needs to be rendered. Instead of doing that, you can use smart components to solve this issue. Of course, there might be use cases where this approach can be helpful, but in general, it's so easy to get tempted to keep adding items to this fragment and face issues in the future So it's not a matter of never using it, but avoiding using it. ![]() GraphQL is designed specially to solve this problem and we are recreating it.Ī simple example of different queries using the same fragment The problem is: what if in a specific component you need now the user job role? And in another component, you need the user friends list? Especially if you're working in a big team, you may easily fall into over fetching issues, and that's what we want the less. If I need the user name and email, why don't I create a userFragment and spread it on every query that needs the user? This mindset might lead us to think we can reuse fragments along with different queries. That's nice! But it may not be so nice when it comes to fragments and queries. So following I'll give some examples from my past experiences about anti-pattern you might avoid when building your queries and fragments to use in your GraphQL Client.Īvoid anti-patterns on your queries and mutations to avoid issues as your application growsĪs smart developers, as we are, we try to avoid repeating ourselves as much as possible (DRY), and so we are into writing reusable codes everywhere and importing them whenever we need it. If you don't architect your queries correctly in the frontend, you might have bad problems in the future and some will be hard to fix. "With great power comes great responsibilities", Uncle Ben It gives more power to the frontend to design how they will be handled. The frontend needs a client (Apollo or Relay) to provide the link with the GraphQL API and so be able to perform queries and mutations as you define them. One of its benefits is providing an API to the frontend so it can fetch the data as it wants without the need of the backend team to provide a specific endpoint for each data combination. GraphQL came to solve lots of problems in how do we handle data access.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |