3 ms·

> 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 ex

by 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
      > Generators are less commonly used, but are a relatively simple language feature Generators are basically unused, full stop. I would go so far as to argue that no major JS library uses generators as a first class concept. I would go even further to argue that proposing a very unpopular control flow technique as a method of state management sounds like the #1 way to cause a library to have a steep learning curve and result in unexpected interactions, especially when being contrasted to algebraic effects. Hooks and algebraic effects lean into the core concept of React as a "pure" functional view layer on top of application state. This is one of React's strengths, and it furthers it by ensuring your components / functions have graceful mechanisms to handle events both of the state change variety AND, as before, user / DOM change type via hooks. It also allows for terse invocation and easy reuse. Enough about this transferable business, writing a reusable pure function is as transferable as it gets. I really don't know what mental burden hooks are putting on developers either. It's pretty simple: you call the same hooks in the same order every time you render your function. There's not that many of them to use, and you don't need all of them by any stretch. All the gotchas that exist already seem like gotchas related to first-class React concepts like state and props and were existing in class components but in a different syntactic sugar. I think we can probably conclude here, because obviously as a fan of React Hooks who thinks they solved a ton of issues in React (to the point I rewrote & improved my entire component library with them), I don't see how using unrelated solutions that require learning entirely new concepts not popular in the domain already will improve the situation.

by nawgz 5y ago

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
    > Generators are less commonly used, but are a relatively simple language feature Generators are basically unused, full stop. I would go so far as to argue that no major JS library uses generators as a first class concept. I would go even further to argue that proposing a very unpopular control flow technique as a method of state management sounds like the #1 way to cause a library to have a steep learning curve and result in unexpected interactions, especially when being contrasted to algebraic effects. Hooks and algebraic effects lean into the core concept of React as a "pure" functional view layer on top of application state. This is one of React's strengths, and it furthers it by ensuring your components / functions have graceful mechanisms to handle events both of the state change variety AND, as before, user / DOM change type via hooks. It also allows for terse invocation and easy reuse. Enough about this transferable business, writing a reusable pure function is as transferable as it gets. I really don't know what mental burden hooks are putting on developers either. It's pretty simple: you call the same hooks in the same order every time you render your function. There's not that many of them to use, and you don't need all of them by any stretch. All the gotchas that exist already seem like gotchas related to first-class React concepts like state and props and were existing in class components but in a different syntactic sugar. I think we can probably conclude here, because obviously as a fan of React Hooks who thinks they solved a ton of issues in React (to the point I rewrote & improved my entire component library with them), I don't see how using unrelated solutions that require learning entirely new concepts not popular in the domain already will improve the situation.