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

I even looked again at my examples and I’m a little annoyed that I even bothered putting a string around my finger for this condescending exchange. I accounted for this case in my second example! Outer function takes props, hooks are a function that expand them. There’s your composition bud.

[nwienert]

Do your part and come back with an example that does the same thing in your syntax.

Don't be lazy and fool yourself into thinking you have a point because you didn't write it out.

I know what problems will come up and I'd like to see how you try and solve them. In the best case you end up with a more verbose syntax for doing the same thing, and in the likely case it will be brittle because you'd have to manually link the instantiations and re-runs, manually ensure you're calling things in order, and may even have to manually dispose things.

[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.