That’s the thing though - hooks aren’t JS. They don’t allow for control flow. Hooks are a language that superficially looks like JS. I’m with you on not inventing new languages, and I wish that React didn’t step so far off that path itself…
This is so silly. Hooks are literally hooks into a scheduling algorithm you are at the mercy of. That scheduling algorithm is pure JS. Of course you don't have classical control flow in someone else's scheduler.
The key users are referring to when talking about "JS vs magic" is that React is just constructing objects and invoking functions, with known semantics, whereas Solid and Svelte are auto-magic-reactive systems without clear semantics rising from the choice to do even more things in their internal black boxes than React, such as never re-rendering components, dark compiler magic on syntax that doesn't naturally map to a JS tree, and other such things
While I use hooks without problem, I also feel like it is an invented mini-language with a lot of extra quirks. Maybe the problem is js does not map elegantly to some of these functional concepts without a good type system.
I’m not what sure what you mean by not “normal” JS functions, though? They’re an API provided by a framework, and — like all APIs — they have specific constraints that govern how they’re used.
To each their own. Although I use react and hooks, for my taste the hooks api is not very clean. All these are implicit not explicit and without linting they can easily result in runtime errors. But maybe I am spoiled by Elm ;)
No they don't, that's a suggested convention
> have restrictions on where to be called (that a program detects)
Yes, it is strange that they opted for this implicit approach, but this is the nature of interacting with a scheduling algorithm in real-time; it is with limitations
I agree they are clearly not unrestricted free-use JS, but they aren't a custom DSL hydrated by compile-time craziness, they are hooks into a scheduling algorithm to help you maintain consistent state in a giant tree. I'm not sure how that is ever going to be free. Perhaps a better type system can help but this is fundamentally complex
This is because hooks are just next() calls on an iterator. Is it magic and entirely because the devs thought it was more beautiful than having to pass a key like state = useState("state", 0)? Absolutely. Does it transcend JS, no.
hooks = [1, 2, 3, 4]
isOne = next(hooks)
isTwo = next(hooks)
if flipcoin()
isThree = next(hooks)
# oops, it's sometimes 3
isFour = next(hooks)They literally are.
> hooks aren’t JS
The code in React executing components relies on hooks running in a consistent order each time the component runs, but the existence of a runtime context that has expectations about side effects (and hooks are side effects) doesn't make it “not javascript”.
I don't have an opinion, just generally curious because it feels very odd that the order of my functions matter.
Adding visual noise to enable subtle bugs may not be a win.
Hooks are functions, and they are executed in the order called from within the component, which is itself a function, just like any other functions calls from within another function.
(The mechanism tracking calls to them and deciding whether the function passed to the hook needs to be called requires them to be called in the same order each time the component is executed; if they were called in order of definition rather than normal execution order this would be true by definition; the whole reason for the rule about not using flow control around them is that they are functions executed in normal flow order.)