3 ms·

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

by 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.
- nawgz 5y ago
  > they are React-specific magic functions that require learning entirely new concepts But they don’t, they’re the same concepts as React always exposed. It literally took no new conceptual learning for me to refactor my entire component library (including forms to graphs to zooming panning charts) from mobx / old react state! It’s a more honest representation of React than the old setState business by a lot

by nawgz 5y ago

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.

nawgz 5y ago
> they are React-specific magic functions that require learning entirely new concepts But they don’t, they’re the same concepts as React always exposed. It literally took no new conceptual learning for me to refactor my entire component library (including forms to graphs to zooming panning charts) from mobx / old react state! It’s a more honest representation of React than the old setState business by a lot