4 ms·

The original promise of React was: UI = f(state) The problems come when you modify state in response to rendering the UI. This seems deceptively natural (and

The original promise of React was: UI = f(state) The problems come when you modify state in response to rendering the UI. This seems deceptively natural (and in fact seems encouraged by on-line tutorials), but leads to "spaghetti fetching" when composing components together - it creates a "feedback loop" that modifies state just because some component happens to mount, which can then modify state further, then cause further mounting/fetching etc... A better approach is to treat fetching as an explicit state change. If user clicks on a button, you do the fetch and modify the state. If that causes some components to be mounted - so be it, but does not cascade any further.

postalrat 2y ago
Did the original react only support stateless components?
aatd86 2y ago
>The problems come when you modify state in response to rendering the UI Yeah don't do that. Rendering shouldn't have such side-effects. Navigation might, but that's not rendering. Is it a common mistake with React?
boredtofears 2y ago
Yes, that's right. The official React docs explain this pretty clearly.
kherud 2y ago
Let's say you want to show a modal, which fetches some data and modifies the state. Based on this, new children are rendered which again fetch state. The problem of "spaghetti fetching" becomes worse the more levels of recursive fetching there are. If I understand you correctly, you argue for fetching all data upfront, and then rendering the modal and all its children all at once. This way you ensure "UI = f(state)" by removing side effects from "f". On the other hand, I can also see some drawbacks: 1. This goes against the idea of fetching data close to where it's used, basically promoting modularization. 2. From the POV of the children, you have to backtrack where their data are coming from. 3. If components always use the same data, you have to duplicate fetching their data everywhere you want to use them. 4. You can't partially show children, but have to wait for everyone to have their data before rendering them. I feel like there are trade-offs to be made here.

postalrat 2y ago

Did the original react only support stateless components?

aatd86 2y ago

>The problems come when you modify state in response to rendering the UI Yeah don't do that. Rendering shouldn't have such side-effects. Navigation might, but that's not rendering. Is it a common mistake with React?

boredtofears 2y ago

Yes, that's right. The official React docs explain this pretty clearly.

kherud 2y ago

Let's say you want to show a modal, which fetches some data and modifies the state. Based on this, new children are rendered which again fetch state. The problem of "spaghetti fetching" becomes worse the more levels of recursive fetching there are. If I understand you correctly, you argue for fetching all data upfront, and then rendering the modal and all its children all at once. This way you ensure "UI = f(state)" by removing side effects from "f". On the other hand, I can also see some drawbacks: 1. This goes against the idea of fetching data close to where it's used, basically promoting modularization. 2. From the POV of the children, you have to backtrack where their data are coming from. 3. If components always use the same data, you have to duplicate fetching their data everywhere you want to use them. 4. You can't partially show children, but have to wait for everyone to have their data before rendering them. I feel like there are trade-offs to be made here.