Admittedly I have not done much work with Angular, but this seems to be more of, "Is Your Home-Grown Per-Entity Data-Fetching Solution a House of Cards?".
The relay idea is nice but it makes a little more sense in a GraphQL-based world, where multiple entities can be fetched in a single call. And I believe the Apollo client does have batching options that will re-compose your queries to limit API calls.
Reading this, it looks like your app was a house of cards because that's exactly how you designed and built it. It was only when it started to hurt your productivity did you realize the mistake.
Honestly, who thought it would be a good idea to have a UI element that appears many times in a single page be responsible for fetching its own data?
This guy is a senior engineer but has never heard of higher-order components or the container pattern? Smells fishy...
I learned from a great dev not long ago that the data structure is often the most important aspect in developing a system. Like you, I was thinking - why would products, likes status and like count be a different call for each individual card. That is obviously inefficient use of both network and drawing as the DOM will be continually drawing as the requests return.
This reminded me that everything old is new again. We keep solving these problems, only to create new tooling that expose these problems in a new - and entirely uninteresting - way for us to solve once more.
5 comments
[ 3.2 ms ] story [ 20.9 ms ] threadThe relay idea is nice but it makes a little more sense in a GraphQL-based world, where multiple entities can be fetched in a single call. And I believe the Apollo client does have batching options that will re-compose your queries to limit API calls.
Honestly, who thought it would be a good idea to have a UI element that appears many times in a single page be responsible for fetching its own data?
This guy is a senior engineer but has never heard of higher-order components or the container pattern? Smells fishy...