4 ms·

I actually did not downvote you anywhere in this thread. > I have useRef and useEffect all over my codebases, I have never used useCallback though useEffect h

I actually did not downvote you anywhere in this thread. > I have useRef and useEffect all over my codebases, I have never used useCallback though useEffect has the caveat that it won't update with useRef. On the initial mount you will probably be fine (because useEffect triggers after first render). But if your component is unmounted (or remounted), then useEffect will not trigger leading to bugs. Which can be quite severe, such as memory leaks. [1] But my point isn't about useRef. My point is there are lots of these types of footguns with hooks in general. And when you hit one of these, you bang your head on the wall until you find someone had the same issue and wrote it up on their blog or stackoverflow. [1] https://medium.com/welldone-software/usecallback-might-be-what-you-meant-by-useref-useeffect-773bc0278ae https://medium.com/welldone-software/usecallback-might-be-wh...

nawgz 5y ago
> useEffect has the caveat that it won't update with useRef Hey, what do you know: > My guess from your tone and general confusion around React is that you expect useRef to have lifecycle hooks when the `current` value changing does not have any lifecycle hooks at all, and somehow your problem with that has made you rail against these hooks Ok, but I'll allow your point that "hooks are complex". What do you propose as an alternative? Have you seen a superior solution the React team is just ignoring? From where I sit, hooks are very terse, they have well defined rules, the error messages they give are useful, and they do a lot of powerful things. Powerful things have edge cases, and your edge case was assuming something would be magically wired for you. Even the instantiation of a `useRef` vs a `useEffect` should give big clues useRef won't update a useEffect; the "touch point" for the useEffect getting the updated values is thru the React component, which has two well-defined stateful flows: state and props. `useRef` is quite clearly (by definition!) neither of these things, and no wiring has ever existed causing any type of ref to re-update your component (and they importantly never have). So, sure, there are limitations and rules you have to pay attention to with hooks... but that's just programming. I don't care that someone accidentally created a memory leak by misusing hooks, you can do all sorts of powerfully broken shit when you don't take effort to misunderstand the underlying library. Hell, I cause my browser to crash semi-regularly when developing in mobx because I cause reactive infinite loops, does that mean mobx is a shit tool and I should stick with redux? Edit: even further to this point, did you read the god damn docs for `useRef`? https://reactjs.org/docs/hooks-reference.html#useref https://reactjs.org/docs/hooks-reference.html#useref literally addresses this caveat you're bitching about EXPLICITLY. "Keep in mind that useRef doesn’t notify you when its content changes", how could it even be more clear no consumer will be notified of updates to your ref?
- RussianCow 5y ago
  > What do you propose as an alternative? There are lots of alternatives, but perhaps the simplest would have been to use async generators. This is how Crank[0] (mentioned elsewhere in this thread) works, and it allows you to do anything (AFAIK) that's possible with hooks with a much simpler and more testable API. > So, sure, there are limitations and rules you have to pay attention to with hooks... but that's just programming. No, it's not. The biggest problem with React hooks is that they are not composed of transferable knowledge, meaning memorizing these rules and patterns does not transfer outside of React; likewise, I can't use much of the knowledge I have already built up over many years of my career when using hooks. It's the same argument that's made against Rails, where you have to learn tons of Rails-specific idioms (on top of having to understand general concepts like relational database access patterns) instead of just writing code in a way that's more direct and intuitive for anyone. My brain has limited RAM. The more things I have to keep in my head when developing against an API, the more likely I am to make a mistake. With every release of React, I seem to have to keep more and more of these details in my brain as I work. Contrast this with something like Svelte, where you really only need to fully grok about two concepts to use it effectively. I understand that this is the tradeoff the React team made, but I'm not convinced it's worth it. [0]: https://crank.js.org/ https://crank.js.org/ and https://crank.js.org/blog/introducing-crank https://crank.js.org/blog/introducing-crank
  - nawgz 5y ago
    > perhaps the simplest would have been to use async generators Honestly, I'm going to be hard-pressed to not give a sarcastic answer to someone proposing "async generators" as "the simplest way to manage state". They are not popular, thus they are not transferable, and I cannot imagine why I would want to use a library which advertises race conditions as a feature when managing complex application state
    - RussianCow 5y ago
      > They are not popular, thus they are not transferable I'm not sure that tracks. Async functions are extremely common, so that can't be it. Generators are less commonly used, but are a relatively simple language feature (also present in other programming languages besides JS) that you can freely use outside of the context of the framework.[0] It's not a big leap to put the two together. Writing and testing an async generator doesn't require any framework-specific incantations. Anyway, I just used Crank as a single example of a possible alternative to React hooks—there are plenty of others that have been suggested. In fairness, it is a complex problem, but other frameworks such as Svelte have solved it in a way that puts much less mental burden on the developer, so it's not like better alternatives don't exist. [0]: As an example, at my last job, we used redux-saga to maintain some parts of our high-level state, so we were already making heavy use of generators. It would not have been a very big leap to then start using generators in our components.

nawgz 5y ago

> useEffect has the caveat that it won't update with useRef Hey, what do you know: > My guess from your tone and general confusion around React is that you expect useRef to have lifecycle hooks when the `current` value changing does not have any lifecycle hooks at all, and somehow your problem with that has made you rail against these hooks Ok, but I'll allow your point that "hooks are complex". What do you propose as an alternative? Have you seen a superior solution the React team is just ignoring? From where I sit, hooks are very terse, they have well defined rules, the error messages they give are useful, and they do a lot of powerful things. Powerful things have edge cases, and your edge case was assuming something would be magically wired for you. Even the instantiation of a `useRef` vs a `useEffect` should give big clues useRef won't update a useEffect; the "touch point" for the useEffect getting the updated values is thru the React component, which has two well-defined stateful flows: state and props. `useRef` is quite clearly (by definition!) neither of these things, and no wiring has ever existed causing any type of ref to re-update your component (and they importantly never have). So, sure, there are limitations and rules you have to pay attention to with hooks... but that's just programming. I don't care that someone accidentally created a memory leak by misusing hooks, you can do all sorts of powerfully broken shit when you don't take effort to misunderstand the underlying library. Hell, I cause my browser to crash semi-regularly when developing in mobx because I cause reactive infinite loops, does that mean mobx is a shit tool and I should stick with redux? Edit: even further to this point, did you read the god damn docs for `useRef`? https://reactjs.org/docs/hooks-reference.html#useref https://reactjs.org/docs/hooks-reference.html#useref literally addresses this caveat you're bitching about EXPLICITLY. "Keep in mind that useRef doesn’t notify you when its content changes", how could it even be more clear no consumer will be notified of updates to your ref?

RussianCow 5y ago
> What do you propose as an alternative? There are lots of alternatives, but perhaps the simplest would have been to use async generators. This is how Crank[0] (mentioned elsewhere in this thread) works, and it allows you to do anything (AFAIK) that's possible with hooks with a much simpler and more testable API. > So, sure, there are limitations and rules you have to pay attention to with hooks... but that's just programming. No, it's not. The biggest problem with React hooks is that they are not composed of transferable knowledge, meaning memorizing these rules and patterns does not transfer outside of React; likewise, I can't use much of the knowledge I have already built up over many years of my career when using hooks. It's the same argument that's made against Rails, where you have to learn tons of Rails-specific idioms (on top of having to understand general concepts like relational database access patterns) instead of just writing code in a way that's more direct and intuitive for anyone. My brain has limited RAM. The more things I have to keep in my head when developing against an API, the more likely I am to make a mistake. With every release of React, I seem to have to keep more and more of these details in my brain as I work. Contrast this with something like Svelte, where you really only need to fully grok about two concepts to use it effectively. I understand that this is the tradeoff the React team made, but I'm not convinced it's worth it. [0]: https://crank.js.org/ https://crank.js.org/ and https://crank.js.org/blog/introducing-crank https://crank.js.org/blog/introducing-crank
- nawgz 5y ago
  > perhaps the simplest would have been to use async generators Honestly, I'm going to be hard-pressed to not give a sarcastic answer to someone proposing "async generators" as "the simplest way to manage state". They are not popular, thus they are not transferable, and I cannot imagine why I would want to use a library which advertises race conditions as a feature when managing complex application state
  - RussianCow 5y ago
    > They are not popular, thus they are not transferable I'm not sure that tracks. Async functions are extremely common, so that can't be it. Generators are less commonly used, but are a relatively simple language feature (also present in other programming languages besides JS) that you can freely use outside of the context of the framework.[0] It's not a big leap to put the two together. Writing and testing an async generator doesn't require any framework-specific incantations. Anyway, I just used Crank as a single example of a possible alternative to React hooks—there are plenty of others that have been suggested. In fairness, it is a complex problem, but other frameworks such as Svelte have solved it in a way that puts much less mental burden on the developer, so it's not like better alternatives don't exist. [0]: As an example, at my last job, we used redux-saga to maintain some parts of our high-level state, so we were already making heavy use of generators. It would not have been a very big leap to then start using generators in our components.