[eyelidlessness]

> Thank you for elaborating! I remember I was really curious when they introduced them, since there had been a lot of focus in the community on stateless functional components before, and the benefits of their purity. Now suddenly they were renamed to function components instead, and as you say, are no longer guaranteed to simply be a function of their props.

Thank you for engaging thoughtfully and with some curiosity! I'm sorry it took me a while to come back to this, but I do want to answer because it's worth exploring.

> What problems do you feel the current hooks API is causing, that could be solved with a different API?

Frankly, once you introduce hooks, you can no longer trust that a function is a function. You can't call it without knowing whether it'll cause side effects. You have to know the hooks internals to know what those side effects actually do, and you have to know the internals of every component before you consider calling a component. It's a breaking change of huge consequence, with no type-level (whether you're using TypeScript or JSDoc or just web docs) indication of what a thing is. So now, allllll functions are not functions.

A way a different API could solve this would be to make the construction and render explicitly separate (just like all of the pre-hooks state APIs for react). Modifying the example from the hooks intro:

        import React, { useState } from 'react';

        function Example() {
          const [count, setCount] = useState(0);

    ---  return (
    +++  return () => (
            <div>
              <p>You clicked {count} times</p>
              <button onClick={() => setCount(count + 1)}>
                Click me
              </button>
            </div>
          );
        }

This isn't where I'd dust off my hands and call it a day. A more ideal hooks API, with chaining and composition in mind, would not just produce free-floating values and state update functions. You could instead wrap props and essentially have a component-local API for a props/state combination where the component still is just a function of props:

    import React, { useState } from 'react';

    function Example(props) ({
      const setCount = useState(props, (props, state) => {
        ...props,
        count: state,
      }));

      return (props) => (
        <div>
          <p>You clicked {props.count} times</p>
          <button onClick={() => setCount(props.count + 1)}>
            Click me
          </button>
        </div>
      );
    }

A comment adjacent to yours (which I don't have time or patience to respond to right now) asked how another API would deal with hooks which are instantiated per-render (which... I guess exists but it's mind-boggling because it's not how hooks are explained to the public), take either of these examples and nest them for each state/props case you'd encounter. This is the Python principle of explicit is better than implicit (which means, yeah, writing a bit more code might be a pain in the butt but you'll understand what's happening), and in FP is referred to as referential transparency ("If I call f(x) -> y, y will always be the same for the same x").

[nwienert]

It is how hooks are explained to the public, for good reason.

This API, which is one I came up with many years ago before hooks as well, is not hooks, and doesn’t have the same properties you’d want. It doesn’t at all allow composition. Honestly, it feels like you haven’t spent much time with hooks if this is your improvement. It's a great case of "making it look better but removing the valuable properties in the name of purity".

I already explained fairly well why you want hooks to be inline in render, as they need to handle side effects, they need to compose with each other and react to changing values, and therefore they need to constantly run to check for updates. It’s 100% how they are used by everyone.

I hope you find time to actually look at what hooks do more closely and find the power behind them.

Again - frontend always had highly stateful and state-changing components, they were just abstracts in ways that suited your tastes better before. But it is just taste you’re talking about, not some inherent superiority. You have to deal with state on the frontend that’s changing often during renders, and you want to handle it locally, and you need to compose and chain various units of logic. You can try and hide that fact behind more syntax, but it doesn’t change the fact that your inner function you defined is depending on an outer closure that is stateful, breaking your law of no functions that act differently when called with the same values.

Anyway, to each his own, if you don’t care enough to actually understand them and contend with what they solve then I won’t try and force you to!

[eyelidlessness]

> It doesn’t at all allow composition.

Of course it does. The most basic programming primitives of composition is functions. Want to compose hooks with these APIs? Call one hook from another. They’re just functions.

Edit: or call one hook-using factory/HOC from another.

> Honestly, it feels like you haven’t spent much time with hooks if this is your improvement

It’s true, I do avoid using them. But I spend a lot of time reading the docs, as well as working with a large variety of different JSX APIs.

> It's a great case of "making it look better but removing the valuable properties in the name of purity".

I don’t know why that’s what you took from my pseudocode, since one of the examples maintained the exact same interface. Why would it be less valuable if hooks-consuming components are factories/HOCs?

> I already explained fairly well why you want hooks to be inline in render, as they need to handle side effects, they need to compose with each other and react to changing values, and therefore they need to constantly run to check for updates. It’s 100% how they are used by everyone.

And all of that is possible with the APIs I suggested.

> I hope you find time to actually look at what hooks do more closely and find the power behind them.

Please don’t condescend. I’m plenty familiar with the material.

> You can try and hide that fact behind more syntax, but it doesn’t change the fact that your inner function you defined is depending on an outer closure that is stateful, breaking your law of no functions that act differently when called with the same values.

It’s not about hiding statefulness, it’s about:

1. Isolating it: this is every letter in the SOLID principles.

2. Maintaining clearly identifiable interfaces that are clear in their boundaries and expected behavior.

In Clojure, a language that's pure FP by default with clearly defined APIs for mutable escape hatches, this is achieved by convention with @ prefixes for state and ! suffixes for dereference. In JS/TS, this is achieved by convention by separating state init from post-init behavior (my factory/HOC example), or by passing/wrapping state (see common redux patterns). Both have corresponding types that make clear what’s going on.

Shoving state and return values into the same space makes that impossible.

[nwienert]

You really don't understand composition as it related to hooks, sorry, it's not condescension, you are arm-chairing something and it's obvious. I could provide a complex example for you and then re-write it in your example, and you'd see how hooks is far more elegant, and maybe I will, but to be honest there's a million examples on the web.

And algebraic effects are a FP concept, go look at OCaml which has been pioneering them, so your appeal to FP purity doesn't even hold.

[eyelidlessness]

> You really don't understand composition as it related to hooks, sorry, it's not condescension, you are arm-chairing something and it's obvious.

You’re being a jerk. You’re not in the least being open to the possibility that I understand the subject matter but have omitted exhaustive detail because I’m typing on a phone in comments on HN. But if there’s something you think I haven’t considered feel free to show a use case, and I’m happy to work with it to show an API I think improves on hooks but accounts for it. Let’s collaborate.

> I could provide a complex example for you and then re-write it in your example, and you'd see how hooks is far more elegant, and maybe I will, but to be honest there's a million examples on the web.

Please provide an example. Let’s have a conversation, not... this.

> And algebraic effects are a FP concept, go look at OCaml which has been pioneering them, so your appeal to FP purity doesn't even hold.

I didn’t appeal to FP purity at all. I explicitly appealed to impurity! I appealed to interfaces that embrace it and clearly delineate it.

[nwienert]

You admitted yourself you've never really used them in practice.

I would never having simply read some docs on Rust's borrow checker having never used it, go to some discussion of experts online and nerdsnipe with a pithy "It's a bad interface" comment without having ever seriously tried it.

You're not being a jerk, just a jerk-off. You're talking out of your ass for fun and you admit you've never actually used it, and your poor example show it clearly.

I mean really, think about it. I was honestly interested in seeing if you had some unique insight but your example has no relation at all to hooks, it would only solve useState but has nothing to do with useEffect which is equally if not more important. You replaced the old React `this.setState` basically and not at all hooks, it's a syntax many have done before, that I had personally invented ~7 years ago well before hooks and used it on a small app, and which solves none of the problems they solve.

And now you want me to personally educate you?

At first I was going to just leave it at this conversation, but you know what, fine, here's your example:

  function Component(props: { isActive: boolean }) {
    const [query, setQuery] = useState('')
    const queryDebounced = useDebouncedValue(query, 200)
    const searchResults = useSearch(queryDebounced)
    const results = useLastValueWhen(searchResults, !props.isActive)

    return <>
      <input onChange={e => setQuery(e.target.value)} />
      {results.map(result => <ResultItem {...result} />)}
    </>
  }

  // these two are easy to write out so leaving out
  const useDebouncedValue = () => // debounce hook
  const useLastValueWhen = (a, b) => // hook that retains last a when b == true

  const useSearch = (query: string) => { // can be used elsewhere
    return useFetch(`http://localhost/search?query=${query}`)
  }
  const useFetch = (url: string, args?: any) => {
    const [state, setState] = useState([])

    useEffect(() => {
      let alive = true
      fetch(url, args).then(res => {
        if (alive) setState(res)
      })
      return () => {
        alive = false
      }
    }, [url, args])

    return state
  }

Please do show your example of this.

[eyelidlessness]

Okay I looked and... I'm not sure why you think this example can't be accomplished with my alternate API. You can compose hooks the exact same way and use them in the outer constructor/HOC function. You can nest said functions to receive incoming props. I honestly don't want to spend the time explaining functions as values and scopes, unless you sincerely think that I'm missing a use case here.

[eyelidlessness]

> You admitted yourself you've never really used them in practice.

No, I said I actively avoid them in practice. That said, I’m acknowledging there’s more here and I’ll come back tomorrow.