[eiriklv]

Hooks are both a blessing and a curse.

The most telling difference after starting to use hooks when working with both junior developers and more seasoned ones is that code that seemingly (and intuitively) behaves in one way actually does something slightly different, or worst case - something entirely different. Most often the culprit is a combination of the hooks themselves, the rules and the more general issue of the dependency array and lack of built-in immutability in the language.

This happened before hooks as well, but the class syntax and lifecycle methods felt like a thinner layer on top of JavaScript. Hooks is a much more proprietary concept that tries to solve a much wider problem - having stateful functions, except they make no sense outside the realm of react as they exist right now. Maybe some form of implementation using generators would bring it closer to the language, but that would most likely introduce it’s own set of challenges.

Don’t get me wrong - I enjoy working with hooks, but it just doesn’t feel quite right that they are so tied to some «magical» implementation that requires a large set of rules to behave as expected. It helps to look into the implementation, and especially to reimplement a simple version of react with hooks yourself - but that’s just not a realistic option for many.

Kudos to all the innovation coming from the React team and community though - I’m sure they think about this stuff all the time.

[ceedan]

Well said. I like the idea of generators if possible, but have no idea if it actually is possible.

> they are so tied to some «magical» implementation that requires a large set of rules to behave as expected 100% agree here & with your sentiment about the Class API

[mrloba]

I tried this, and it's possible using a monadic interface. Just like replacing promise.then with async await you can replace monad.flatmap with generator yields. But I've already seen this concept discussed by the react team and it seemed they didn't like it.

What's cool with a monadic interface is that you can create lots of other interesting things, as long as you adhere to the interface. For instance, I think it's possible to achieve something similar to async render functions without specific support for it.

[zestyping]

> Maybe some form of implementation using generators would bring it closer to the language

That's what https://crank.js.org does. I haven't tried building a real app on it yet, but I have to say it does seem pretty elegant and promising at a first glance.

[rashkov]

Thanks for the idea. I've formulated a small version of this problem as follows, and provided a solution elsewhere in this thread:

  const React = /* Implement this */;

  function HelloComponent(){
    const [myNumber, setMyNumber] = React.useState(0);
    // Simulate rendering data to a screen
    console.log("My number:", myNumber);
    // Simulate rendering a clickable button
    const click = ()=> setMyNumber((num)=> num + 1);
    return click; 
  }

  React.mount(HelloComponent); // prints 0
  React.simulateClick(HelloComponent); // prints 1
  React.simulateClick(HelloComponent); // prints 2
  React.simulateClick(HelloComponent); // prints 3

[thursday0987]

this is a pointless example. it doesn't render anything, and therefore doesn't have to deal with React's render cycle.

also, you shouldn't use useState unless you want it to rerender, which you don't because you're printing to console. use a ref instead for myNumber.

the problem you are trying to solve, updating a number if someone clicks on something, is already solved in React:

    const HelloComponent => React.forwardRef((props, forwardRef) => {
     const myNumber = useRef(0)
     const printToConsole = () => {
        myNumber.current = myNumber.current + 1
        console.log("My Number:", myNumber.current)
      }
      render (
        <div ref={forwardRef} onClick={printToConsole}>click me</div>
      )
    }

then you can simply trigger a click by calling .click() on the forwarded ref wherever you happen to mount it.