I also posted about implementing a similar component. I didn’t cover handling the error state (so I appreciate that you did), but one problem I’ve run into was that when switching between two subtrees with the data loader component at the same level, the component wouldn’t actually be unmounted, which broke a few of my assumptions. I think wrapping it in another component like you did in the final CommentsSection implementation fixes this, though.
Also somebody in the comments also pointed to the Apollo Query component, which has yet another API but essentially does the same thing.
Old components may not be unmounted because the final tree contains the same component in between state changes. This can be the case if all your sub-components are divs, for example. In that case, React will happily not rebuild the component, and instead will just change the props of it. Then you need to use the componentWillReceiveProps, that only complicates it and makes for more antipatterns and worse code.
Depending on how you can refactor it, you can trick React into rebuilding the whole component, for example by returning an array of a single component with a random key, or some kind of key that changes when you want the DOM tree to be rebuilt. It is a bit annoying, but it’s significantly less annoying than the componentWillReceiveProps route.
Then you need to use the componentWillReceiveProps, that only complicates it and makes for more antipatterns and worse code.
Yep, componentWillReceiveProps has only caused me problems. That’s why I prefer hooks in general, they make it easier to spot this kind of errors and correct them “the right way”.
I also posted about implementing a similar component. I didn’t cover handling the error state (so I appreciate that you did), but one problem I’ve run into was that when switching between two subtrees with the data loader component at the same level, the component wouldn’t actually be unmounted, which broke a few of my assumptions. I think wrapping it in another component like you did in the final
CommentsSectionimplementation fixes this, though.Also somebody in the comments also pointed to the Apollo Query component, which has yet another API but essentially does the same thing.
Old components may not be unmounted because the final tree contains the same component in between state changes. This can be the case if all your sub-components are divs, for example. In that case, React will happily not rebuild the component, and instead will just change the props of it. Then you need to use the componentWillReceiveProps, that only complicates it and makes for more antipatterns and worse code.
Depending on how you can refactor it, you can trick React into rebuilding the whole component, for example by returning an array of a single component with a random key, or some kind of key that changes when you want the DOM tree to be rebuilt. It is a bit annoying, but it’s significantly less annoying than the componentWillReceiveProps route.
Yep, componentWillReceiveProps has only caused me problems. That’s why I prefer hooks in general, they make it easier to spot this kind of errors and correct them “the right way”.