6 ms·

Do it at the top-level. React components shouldn't be managing their own data fetches or computation. They should take event handlers that indicate something

Do it at the top-level. React components shouldn't be managing their own data fetches or computation. They should take event handlers that indicate something has happened on the page, and then delegate that back up the tree until the App decides what to do with them. The App is then responsible for making the relevant fetches, massaging the data into a form suitable for display on the page, and updating the state. Components, to the greatest extent possible, should be stateless and react only to changes in props. If they do need state it should be for things local to the view (eg. the position of a slider, the currently selected tab, or the hidden/shown state of an expando). 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.

PKop 7y ago
>Do it at the top-level. Which top level? 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.
- nickdandakis 7y ago
  Not to mention you can still keep your pure UI components separate from your components that have data fetching logic (aka containers). 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.
  - PKop 7y ago
    Every one has reasons for their concerns, and complexity is something to be concerned of... but it seems most critics are arguing from a view which implies they don't support the "declarative component" model itself. 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.)
- lhorie 7y ago
  > Requires a lot of coordination code, duplication, and coupling of your entire component hierarchy to each other no? 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.
  - PKop 7y ago
    Definitely, if you want to say that another framework itself better solves all of the very real problems that need solving... makes perfect sense. 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..

PKop 7y ago

>Do it at the top-level. Which top level? 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.

nickdandakis 7y ago
Not to mention you can still keep your pure UI components separate from your components that have data fetching logic (aka containers). 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.
- PKop 7y ago
  Every one has reasons for their concerns, and complexity is something to be concerned of... but it seems most critics are arguing from a view which implies they don't support the "declarative component" model itself. 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.)
lhorie 7y ago
> Requires a lot of coordination code, duplication, and coupling of your entire component hierarchy to each other no? 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.
- PKop 7y ago
  Definitely, if you want to say that another framework itself better solves all of the very real problems that need solving... makes perfect sense. 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..