Without data fetching or manipulating, you have nothing to render.
Aside from keeping rendering lightweight and never needing to block, this architecture also:
1.) Lets the app batch up RPCs to minimize network traffic.
2.) Lets you easily swap out the network layer for mock data so you can develop the UI before the server is ready (often very important because backend dev tends to be slower than frontend).
3.) Lets you handle failures sensibly. Oftentimes a failed RPC requires that you make non-local changes to the UI (eg. display a butterbar, change page layout to not display a component, display an alternate component).
4.) Lets you easily add logging, tracing, and performance profiling capability to your network layer.
5.) Keeps your UI components reusable so they aren't coupled to a specific app or backend.
6.) Optimally handles cases where data (derived) from the fetch shows up in multiple places in the UI. One classic example of this is a table where the total count of results is in a UI element elsewhere on the page; another is when logging in changes the elements you're shown.
Requires a lot of coordination code, duplication, and coupling of your entire component hierarchy to each other no?
Still doesn't solve disparities in data loading completion across different services. Render giant loading spinner or the entire app?
Plus, you will be overfetching if everything is pulled into top level components.
For exactly the reason componentizing the markup was a good idea, it is beneficial to breakup data loading and manipulation concerns across components, while also being able to reuse some of this logic through abstractions (hooks).
>Keeps your UI components reusable so they aren't coupled to a specific app or backend.
They are coupled to each other by virtue of where you define them in the hierarchy and which props they need to pass to and receive from each other.
Components are highly reusable.
Containers are coupled to specific API calls or logic.
I still default to doing as much data fetching on the top-level page component as possible and trickling data down. But if there's certain logic or data fetching I re-use in multiple places that don't need to block the whole page, I'll definitely refactor that into hooks + containers and delegate that data fetching lower in the tree.
These added features are simply extending that paradigm in a natural way that supports better UX, within the constraints of the javascript language.
Nobody says they are easy problems to solve, but it's sort of a non-sequitur to argue alternatives that don't solve them (or don't absolve one of having to solve them still.)
Only if we tunnel-vision to a narrow definition of "idiomatic patterns in React". In Angular, for example, this is solved via a DI system. In React, you actually get much higher level of coupling because all orchestration-type things need to go through context providers (meaning a given component may only work if certain providers are installed at the top level of the React tree). In Angular, a coupling mismatch issue would throw an error saying X component requires Y dependency and the solution would be to simply inject what is missing. No need to go edit your layout file or whatever.
The coupling I'm mainly referring to is within your own app hierarchy. Moving/adding components around within your app requires editing the long chain of component hierarchies and data dependencies.
Yes injection works to solve, but isn't this similar to hooks (encapsulating reusable logic/data fetching)? Whether a top level Context provider (that will also throw an error if not provided) or injection.. is there much of a difference? And does this not seem less coupled than prop drilling through the entire component chain?
In the context of a discussion about UX, loading states, spinners, concurrent rendering though, does Angular address this? I'm not that familiar with it..
It's basically the Law of Demeter applied to UI components, and has both the benefits and the pitfalls of the LoD:
https://en.wikipedia.org/wiki/Law_of_Demeter
Boilerplate code goes up, method signatures get duplicated more (though JS has easy varargs & spread operators, so this can be minimized), method logic is less duplicated, and coupling is decreased.
> Still doesn't solve disparities in data loading completion across different services. Render giant loading spinner or the entire app?
You have a choice depending on product concerns. You can render a single loading spinner for the app. You can render individual spinners for different loading components (just pass the 'loading' prop into each of them separately), but have them all resolve at the same time. Or you can issue separate RPCs for each, as if the component had made the request itself, and have each component re-render as the request comes back.
The nice thing is that this choice is not embedded within the component itself, so you could for example start out by rendering a single global spinner until a single global RPC comes back, and then as you build out the backend and separate calls into different RPCs, change component rendering to incrementally show the new data.
> Plus, you will be overfetching if everything is pulled into top level components.
Again, this is a product tradeoff. Do multiple components display data that changes when an event happens on one component? It makes sense to batch up the RPCs then, because they'll always be triggered together anyway. Or is each component displaying data that is manipulated only by that component? Then give it its own RPC, but you should still kick it off at the top-level and delegate up the tree so that you can change this behavior easily.
In my experience, UIs designed by frontend engineers tend to have lots of RPCs that are both kicked off by and only affect a single component, while UIs designed by UI designers and CEOs (and users themselves) tend to have a lot of non-local changes throughout the UI in response to an event in one component. This is a source of tension between these groups, but only one side is signing the paychecks.
The standard React application renders a few levels down, investigates the document location and matches against routes, renders a few more levels, discovers there is some necessary data missing, fetches it, renders a few more levels down, realizes there's more data missing, stops and waits for it, etc.
This isn't a failing of React per se, but rather of how people use it.
React itself was created in opposition to arbitrary separation of concerns dogma. The concern is the component, the entity encompassing both UI and data manipulation code, as well as styling. Separating all of these parts into isolation does not result in more maintainable code or better UX.
https://www.youtube.com/watch?v=x7cQ3mrcKaY
Components have always had JSX markup along with data manipulation logic. CSS in JS and styling co-located with component extended this consolidation of cross-cutting concerns.
These, along with not manually updating DOM state as you mention, all fall under declarative aspects of React.. which concurrent rendering and Suspense are consistent with and essentially an extension of.
That's exactly what this feature is doing -- making the view layer more flexible in how it responds to the data received.