You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
That shouldn't be the case if you're using fragments correctly - you should be passing only the data that each component needs.
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.
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.
Note that the
<User />
component and it's related fragmentUser_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.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.
The text was updated successfully, but these errors were encountered: