2 ms·

Components using hooks are not pure functions. The necessity(!) to wrap each and every basic JavaScript API (useEffect v. setTimeout, useLayoutEffect v. queueM

Components using hooks are not pure functions. The necessity(!) to wrap each and every basic JavaScript API (useEffect v. setTimeout, useLayoutEffect v. queueMicrotask, useInterval and usePromise v. using Intervals and Promises) does not at all showcase the "expressive power" of React. It was fun while it lasted but it's time to let go. React's become JQuery

steve_adams_86 5y ago
How would you use setTimeout to replace useEffect? useEffect works by running on each render (no dependencies) or running when rendering and dependencies changed. Where does a timeout factor in? useLayoutEffect also doesn't work based on the microtask queue - it uses React's internal scheduler, which I would imagine makes sense in the context of the library. Replicating it with queueMicrotask is probably not a trivial task.
phailhaus 5y ago
That's like saying "ugh Python's become JQuery because XXX function is not part of the standard library." You seem to be upset that people are building more useful primitives using the hooks paradigm? React deliberately ships with only a few hooks, more or less the fundamental ones that you cannot yourself implement. They left the rest up to the community to explore, because it is very difficult to predict how a new paradigm will be used. Hooks isn't just useState and useEffect, hooks are a way of writing reactive logic. It is very impressive that the community is able to produce new tools that simplify annoying problems like managing asynchronous state with just a single function, in a way that can be more-or-less dropped into any existing component.
- mikojan 5y ago
  The ReactJS community is not simplifying annoying problems. The JavaScript community did that. The ReactJS community is quite literally re(!)-implementing promises here to make them work with a purported library(!). This is insane. You shouldn't need to download useConsole from npm.
  - phailhaus 5y ago
    > The ReactJS community is quite literally re(!)-implementing promises here to make them work with a purported library(!). What? I don't think you understand hooks very well. You can already use promises with hooks by creating them and then calling `setState` however you want in the callbacks to deal with pending/success/error. It's such a common pattern that the community has developed a `usePromise` hook that abstracts away all that logic for you, meaning that you can treat any promise as a stateless value to be consumed by your components, one that will automatically manage its state for you and guarantee your UI is consistent without any additional effort. I never have to deal with managing asynchronous state ever again! That's what a good library does: allow you to build reusable components that abstract away complexity. Hooks let you abstract away state management, the bane of UI development. I can tell you from experience dating back to Backbone and Marionette that it has never been so easy to deal with async state before. Coupled with Typescript, I also get the guarantee that I've accounted for every possible case (success, pending, error). It's a zero-cost abstraction. What's your experience with hooks?
    - mikojan 5y ago
      I understand modern JavaScript development is a giant leap forwards compared to JavaScript development 10 years ago. Nobody is arguing with that. Your last statement is completely wrong, though. ReactJS/hooks are not zero-cost abstractions. They impose a cost both in terms of real performance as well as cognitive complexity. And when you run into performance issues you're almost certainly confronted with this pattern of escalation (assuming you've done nothing wrong): 1. Litter your Code with calls to useMemo/useCallback. 2. Re-evaluate your business needs because you've exhausted the hooks "primitive". 3. Iteratively and painstakingly force more and more logic out of ReactJS' scope until you've met your benchmark targets. Following along quickly requires intricate knowledge of poorly documented but overwhelmingly complex ReactJS internals alongside(!) whatever knowledge of JavaScript internals is required. You have to have and process 2 complex, unique and outright byzantine models in your mind simultaneously. Compare this to Angular(!) which lets you use standard web APIs, additionally exposes useful standard(!) primitives, and(!) provides you with straight-forward(!) opt-out mechanisms. Yet here we are, quite literally downloading useInterval from npm 40,000 times a week.

steve_adams_86 5y ago

How would you use setTimeout to replace useEffect? useEffect works by running on each render (no dependencies) or running when rendering and dependencies changed. Where does a timeout factor in? useLayoutEffect also doesn't work based on the microtask queue - it uses React's internal scheduler, which I would imagine makes sense in the context of the library. Replicating it with queueMicrotask is probably not a trivial task.

phailhaus 5y ago

That's like saying "ugh Python's become JQuery because XXX function is not part of the standard library." You seem to be upset that people are building more useful primitives using the hooks paradigm? React deliberately ships with only a few hooks, more or less the fundamental ones that you cannot yourself implement. They left the rest up to the community to explore, because it is very difficult to predict how a new paradigm will be used. Hooks isn't just useState and useEffect, hooks are a way of writing reactive logic. It is very impressive that the community is able to produce new tools that simplify annoying problems like managing asynchronous state with just a single function, in a way that can be more-or-less dropped into any existing component.

mikojan 5y ago
The ReactJS community is not simplifying annoying problems. The JavaScript community did that. The ReactJS community is quite literally re(!)-implementing promises here to make them work with a purported library(!). This is insane. You shouldn't need to download useConsole from npm.
- phailhaus 5y ago
  > The ReactJS community is quite literally re(!)-implementing promises here to make them work with a purported library(!). What? I don't think you understand hooks very well. You can already use promises with hooks by creating them and then calling `setState` however you want in the callbacks to deal with pending/success/error. It's such a common pattern that the community has developed a `usePromise` hook that abstracts away all that logic for you, meaning that you can treat any promise as a stateless value to be consumed by your components, one that will automatically manage its state for you and guarantee your UI is consistent without any additional effort. I never have to deal with managing asynchronous state ever again! That's what a good library does: allow you to build reusable components that abstract away complexity. Hooks let you abstract away state management, the bane of UI development. I can tell you from experience dating back to Backbone and Marionette that it has never been so easy to deal with async state before. Coupled with Typescript, I also get the guarantee that I've accounted for every possible case (success, pending, error). It's a zero-cost abstraction. What's your experience with hooks?
  - mikojan 5y ago
    I understand modern JavaScript development is a giant leap forwards compared to JavaScript development 10 years ago. Nobody is arguing with that. Your last statement is completely wrong, though. ReactJS/hooks are not zero-cost abstractions. They impose a cost both in terms of real performance as well as cognitive complexity. And when you run into performance issues you're almost certainly confronted with this pattern of escalation (assuming you've done nothing wrong): 1. Litter your Code with calls to useMemo/useCallback. 2. Re-evaluate your business needs because you've exhausted the hooks "primitive". 3. Iteratively and painstakingly force more and more logic out of ReactJS' scope until you've met your benchmark targets. Following along quickly requires intricate knowledge of poorly documented but overwhelmingly complex ReactJS internals alongside(!) whatever knowledge of JavaScript internals is required. You have to have and process 2 complex, unique and outright byzantine models in your mind simultaneously. Compare this to Angular(!) which lets you use standard web APIs, additionally exposes useful standard(!) primitives, and(!) provides you with straight-forward(!) opt-out mechanisms. Yet here we are, quite literally downloading useInterval from npm 40,000 times a week.