4 ms·

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

• 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.
      • RussianCow 5y ago
        > 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. Putting aside the fact that hooks are not the same as algebraic effects, I think it's funny that you believe algebraic effects are simpler to learn and reason about than generators. I'll grant you that it's pretty easy to get up and running using hooks, but I've met few frontend engineers who could actually explain to me the entire lifecycle of a complex functional component in detail. You can argue that those are not very good engineers, but I've seen this far too often not to blame the tool. > Enough about this transferable business, writing a reusable pure function is as transferable as it gets. But they're not pure! As soon as you call `useState` or any other hook, you lose all semblance of purity in your components, because the functions are now tightly bound to the React life cycle and can't be called or tested in any way without that context. Debugging and testing hooks means using React-specific tools that aren't applicable anywhere else, and stack traces become significantly less meaningful than they were with the class-based lifecycle methods. > I really don't know what mental burden hooks are putting on developers either. The "rules of hooks" are weird and counter-intuitive, and necessitate a lot more care with what would otherwise be simple refactors. That said, I could grant that it's not a big deal if that was the only gotcha, but hooks are full of them. For instance, I can't tell you how many bugs I've encountered related to the dependency array passed into `useEffect` and `useCallback`—it's very easy to have your component render too often or not often enough in ways that are not immediately obvious in a code review. Finding bugs related to these dependencies can be really painful, whereas class-based components let you easily debug updates by plopping a breakpoint into `componentDidUpdate`. > I don't see how using unrelated solutions that require learning entirely new concepts not popular in the domain already will improve the situation. Yeah, I think we can agree to disagree here, because this is exactly what I think about hooks: they are React-specific magic functions that require learning entirely new concepts that are meaningless outside of React. To each either own.