5 ms·

> React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways. The built-in React way of doing that is with c

> React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways. The built-in React way of doing that is with context.

PaulHoule 4y ago
A classic example of: "you had one problem, now you have ten problems". That's fine if you aren't writing any unit tests or trying to fix bugs with the debugger. If context are in use you might have some 'simple' system with 10 components that shows 150 components in the React component viewer most of which are worthless context blocks that are just there to waste your attention and probably the CPU and memory of your computer. Does Micron pay Facebook a commission for all the RAM this sells? Maybe people who are trying to keep their code obfuscated think it is a big win. I am glad that the React team has painted themselves into a corner and they can't seem to successfully land new malfeatures like context, hooks, etc. It seems like they are re-arraigning the deck chairs on the Titanic repeatedly to prepare for the threaded rendering changes that they (hopefully) won't be able to deliver so at least the React development experience is not going to degrade quickly.
- stillkicking 4y ago
  >React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways So let's first back up and recognize that this earlier statement was flat out wrong. React does provide a systematic answer for this. Second, not only does it have a systematic answer, but it memoizes quite well because React will not re-render children if the `children` prop is identical to the previous render, even if you don't use `memo()`. This means it is quite cheap to have context providers update, even if you nest 2 or 3 of them. The big issue with React in my experience is just that developers are lazy af and will stubbornly refuse to read even the tersest of docs even if they are encountering a new paradigm, like declarative and reactive UI. The result is a giant spaghetti mess of their own creation, which they then blame the framework for. You can make React fast and you can keep it clean, all you have to do is topologically sort your data by the frequency of how quickly it changes. That's it. That's the trick.
  - vbezhenar 4y ago
    My issue with React is that it's truly hard. It markets itself as easy but it's not. I have 20 years of programming experience, I dealt with UI a lot, I used WinAPI, Java Swing, I know JS and HTML pretty well. I'm fine with reactive programming or async stuff. Yet I often struggle with React. I'm not a full-time web developer, I admit, I'm more like full-stack developer but when I need to write novel React code, I struggle a lot. For example recently I wanted to use a promises in React app. I mean: promises are as native to JS as it gets. Surely React should have first-class support for promises. Nope. So I started to write custom hook. usePromise. Like useEffect, but for promises. Well, it would not be hard. But apparently React likes to call useEffect twice for dev mode. So I need to have a reliable cancellation. How do we cancel stuff in web? With AbortController, right. Does React heard about AbortController? Nope. So I need to integrate AbortSignal within my usePromise hook. I read famous Dan Abramov article, I read other articles, I spent days tinkering around this thing, I wrote several implementations. All of those implementations are faulty. Here's my latest one: https://pastebin.com/WBctCBpc https://pastebin.com/WBctCBpc. Technically it works. But it contains unpure reducer function. It's not broken in current React version. But who knows how react dev mode will torture my reducer in the next version. I have to admit that I enjoyed toying with this stuff. But it definitely counter-productive to business values. Now I know that this is all solved and I should just use react-query or something similar. Well, I have my reasons to avoid it. But my point still holds: React is hard, React is not well integrated with JS and Web. And probably React will get better in the future. I've heard about suspension stuff which might just be what I need, but it's not there yet.
    - scotty79 4y ago
      What does usePromise is supposed to do?
      - vbezhenar 4y ago
        It's supposed to run provided promise and return its status. If deps changed or component is unmounted while promise is pending, it should inform currently running promise using AbortSignal. And it should handle edge cases (e.g. promise is changed, second promise is started but first promise ignored abort signal and resolved to a value. This value should be ignored). Basically it should remove any boilerplate from user of this API and handle edge cases.

> React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways. The built-in React way of doing that is with context.

PaulHoule 4y ago

A classic example of: "you had one problem, now you have ten problems". That's fine if you aren't writing any unit tests or trying to fix bugs with the debugger. If context are in use you might have some 'simple' system with 10 components that shows 150 components in the React component viewer most of which are worthless context blocks that are just there to waste your attention and probably the CPU and memory of your computer. Does Micron pay Facebook a commission for all the RAM this sells? Maybe people who are trying to keep their code obfuscated think it is a big win. I am glad that the React team has painted themselves into a corner and they can't seem to successfully land new malfeatures like context, hooks, etc. It seems like they are re-arraigning the deck chairs on the Titanic repeatedly to prepare for the threaded rendering changes that they (hopefully) won't be able to deliver so at least the React development experience is not going to degrade quickly.

stillkicking 4y ago
>React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways So let's first back up and recognize that this earlier statement was flat out wrong. React does provide a systematic answer for this. Second, not only does it have a systematic answer, but it memoizes quite well because React will not re-render children if the `children` prop is identical to the previous render, even if you don't use `memo()`. This means it is quite cheap to have context providers update, even if you nest 2 or 3 of them. The big issue with React in my experience is just that developers are lazy af and will stubbornly refuse to read even the tersest of docs even if they are encountering a new paradigm, like declarative and reactive UI. The result is a giant spaghetti mess of their own creation, which they then blame the framework for. You can make React fast and you can keep it clean, all you have to do is topologically sort your data by the frequency of how quickly it changes. That's it. That's the trick.
- vbezhenar 4y ago
  My issue with React is that it's truly hard. It markets itself as easy but it's not. I have 20 years of programming experience, I dealt with UI a lot, I used WinAPI, Java Swing, I know JS and HTML pretty well. I'm fine with reactive programming or async stuff. Yet I often struggle with React. I'm not a full-time web developer, I admit, I'm more like full-stack developer but when I need to write novel React code, I struggle a lot. For example recently I wanted to use a promises in React app. I mean: promises are as native to JS as it gets. Surely React should have first-class support for promises. Nope. So I started to write custom hook. usePromise. Like useEffect, but for promises. Well, it would not be hard. But apparently React likes to call useEffect twice for dev mode. So I need to have a reliable cancellation. How do we cancel stuff in web? With AbortController, right. Does React heard about AbortController? Nope. So I need to integrate AbortSignal within my usePromise hook. I read famous Dan Abramov article, I read other articles, I spent days tinkering around this thing, I wrote several implementations. All of those implementations are faulty. Here's my latest one: https://pastebin.com/WBctCBpc https://pastebin.com/WBctCBpc. Technically it works. But it contains unpure reducer function. It's not broken in current React version. But who knows how react dev mode will torture my reducer in the next version. I have to admit that I enjoyed toying with this stuff. But it definitely counter-productive to business values. Now I know that this is all solved and I should just use react-query or something similar. Well, I have my reasons to avoid it. But my point still holds: React is hard, React is not well integrated with JS and Web. And probably React will get better in the future. I've heard about suspension stuff which might just be what I need, but it's not there yet.
  - scotty79 4y ago
    What does usePromise is supposed to do?
    - vbezhenar 4y ago
      It's supposed to run provided promise and return its status. If deps changed or component is unmounted while promise is pending, it should inform currently running promise using AbortSignal. And it should handle edge cases (e.g. promise is changed, second promise is started but first promise ignored abort signal and resolved to a value. This value should be ignored). Basically it should remove any boilerplate from user of this API and handle edge cases.