4 ms·

> why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. The fact that you are askin

> why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. > Oh, you just hated React all along, so you probably never understood it. Sure, asshole. I've only been using React for 6 years now. But whatever.

nawgz 5y ago
> The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. Or that you are doing questionable things with it? 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. Feel free to enlighten me - I have useRef and useEffect all over my codebases, I have never used useCallback though > Sure, asshole. I've only been using React for 6 years now Your own words: "React, itself, is a mess. Always has been". That's a comical statement to make if you're not emotionally biased against a library. Especially when that library is well-organized, with strong lifecycle guarantees, and gives you the strongest out-of-the-box composability of any comparable web framework. But no, it's you that's right, React sucks and doesn't work, it's the top JS library because JS developers are idiots right? Edit: it additionally appears you downvoted my entire thread contribution, so I'm going to take it as you don't understand the point of useRef at all. :)
- deckard1 5y ago
  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

> The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. Or that you are doing questionable things with it? 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. Feel free to enlighten me - I have useRef and useEffect all over my codebases, I have never used useCallback though > Sure, asshole. I've only been using React for 6 years now Your own words: "React, itself, is a mess. Always has been". That's a comical statement to make if you're not emotionally biased against a library. Especially when that library is well-organized, with strong lifecycle guarantees, and gives you the strongest out-of-the-box composability of any comparable web framework. But no, it's you that's right, React sucks and doesn't work, it's the top JS library because JS developers are idiots right? Edit: it additionally appears you downvoted my entire thread contribution, so I'm going to take it as you don't understand the point of useRef at all. :)

deckard1 5y ago
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