4 ms·

Without data fetching or manipulating, you have nothing to render.

couchand 7y ago
Yes, but don't do it from within your view. Fetch the data you need and provide it to the view. 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.
- weberc2 7y ago
  As an ignorant and neutral bystander, I’m really curious why this is downvoted and would be interested in reading the rebuttal (seems like I could learn something).
  - chacham15 7y ago
    React isnt the one mandating how its used. It can be used in the way that the GP is talking about, but you can also keep the data entirely separate. Redux et al do exactly that. The main thing that the GP is missing is that, like with video games, in order to keep the view rendering smoothly, you need something like double buffering so that if the render isnt complete, you dont block. That is independent of how the data is being provided.
  - PKop 7y ago
    Because 4 or 5 years of real world React development have proven them inadequate suggestions. 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.
    - couchand 7y ago
      No, React was created in opposition to the fact that we used to manually update the DOM because that's all we had tools for.
      - PKop 7y ago
        Rethinking best practices absolutely addressed misapplication of separation of concerns. https://www.youtube.com/watch?v=x7cQ3mrcKaY 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.
      - mosdl 7y ago
        No, React was created to allow contractors to write code fast and not worry about optimization.
- crooked-v 7y ago
  My general lean here has been to use a library like redux-first-router (https://github.com/faceyspacey/redux-first-router https://github.com/faceyspacey/redux-first-router) to have this data lookup stuff happen based on routing and existing Redux state, and conditional rendering wrapping for specific components using that data (for example, https://github.com/acdlite/recompose/blob/master/docs/API.md#branch https://github.com/acdlite/recompose/blob/master/docs/API.md...).
- ng12 7y ago
  > Fetch the data you need and provide it to the view. That's exactly what this feature is doing -- making the view layer more flexible in how it responds to the data received.
nostrademons 7y ago
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.

Yes, but don't do it from within your view. Fetch the data you need and provide it to the view. 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.

weberc2 7y ago
As an ignorant and neutral bystander, I’m really curious why this is downvoted and would be interested in reading the rebuttal (seems like I could learn something).
- chacham15 7y ago
  React isnt the one mandating how its used. It can be used in the way that the GP is talking about, but you can also keep the data entirely separate. Redux et al do exactly that. The main thing that the GP is missing is that, like with video games, in order to keep the view rendering smoothly, you need something like double buffering so that if the render isnt complete, you dont block. That is independent of how the data is being provided.
- PKop 7y ago
  Because 4 or 5 years of real world React development have proven them inadequate suggestions. 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.
  - couchand 7y ago
    No, React was created in opposition to the fact that we used to manually update the DOM because that's all we had tools for.
    - PKop 7y ago
      Rethinking best practices absolutely addressed misapplication of separation of concerns. https://www.youtube.com/watch?v=x7cQ3mrcKaY 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.
    - mosdl 7y ago
      No, React was created to allow contractors to write code fast and not worry about optimization.
crooked-v 7y ago
My general lean here has been to use a library like redux-first-router (https://github.com/faceyspacey/redux-first-router https://github.com/faceyspacey/redux-first-router) to have this data lookup stuff happen based on routing and existing Redux state, and conditional rendering wrapping for specific components using that data (for example, https://github.com/acdlite/recompose/blob/master/docs/API.md#branch https://github.com/acdlite/recompose/blob/master/docs/API.md...).
ng12 7y ago
> Fetch the data you need and provide it to the view. That's exactly what this feature is doing -- making the view layer more flexible in how it responds to the data received.

nostrademons 7y ago

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.