Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Article: using fragments correctly #22

Open
benjie opened this issue Dec 2, 2024 · 0 comments
Open

Article: using fragments correctly #22

benjie opened this issue Dec 2, 2024 · 0 comments

Comments

@benjie
Copy link
Owner

benjie commented Dec 2, 2024

If I manually merge them to a single query I'm losing out on a key pro of it: less separation of concerns on front end code.

That shouldn't be the case if you're using fragments correctly - each level should only need to know about itself and the children it renders.

If there's one "big" query at the top of the component tree, I'd have to start passing way more state down to the individual components

That shouldn't be the case if you're using fragments correctly - you should be passing only the data that each component needs.

if I want to load "more follow suggestions" I'd need to pass a fetchMore kind of callback down the stack

That shouldn't be the case if you're using fragments correctly - instead you should use a separate dedicated query specifically to fetch more of this one resource without requesting the rest of the information the original query needed.

It also generally means more effort to add features as I need to make changes to both the component and the top-of-tree query.

That shouldn't be the case if you're using fragments correctly - you should only need to add details of the children your component renders, e.g.

 const User = ({ user }) => {
   return (
     <div>
       <span>{user.name}</span>
+      <Avatar user={user} />
     </div>
   );
 }
 const User_User = gql`
   fragment User_User on User {
     name
+    ...Avatar_User
   }
+  ${Avatar_User}
 `;

Note that the <User /> component and it's related fragment User_User are the only things that need to know that the Avatar is now being rendered - we've not had to inform any higher level.

Finally I think it also hurts client side performance since the entire tree has to be re-rendered every time to query is updated

That shouldn't be the case if you're using fragments correctly since data is stored to a normalized cache, so only the parts that change should need to re-render. (The top component might need to re-render but it should stop as soon as it renders a child whose data dependencies haven't changed.) I'm not so certain on how this part behaves, I'd have to actually test it - and it may well differ between Apollo and Relay for example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant