Ehh it really doesn't change the semantics of your code, hooks are just iterables and you access them by calling next(). In an alternative world they would be a mapping that you give unique names like useState("mystate", ...) and then order and if statements would be irrelevant.
Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run.
Like it's janky and reaches through layers but it's not up and rewriting your code.
> hooks are just iterables and you access them by calling next()
In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again.
> Also you're just just
Ah yes. That "just" again
Edit:
> just passing a callback function to React and then giving it some pointers to data
Thing is, in plain JavaScript if it was a callback function, it could be called anything and live anywhere. However, these functions have to be named with a `use` prefix and have limitations on how they can be called.
And you can put hooks in if statements too, but like iterables it won't have the effect you probably want.
it = ["hello", "world", "foo", "bar"]
shouldbehello = next(it)
shouldbeworld = next(it)
if sometimes_true_sometimes_false:
shouldbefoo = next(it)
# if the conditional is false this will be foo, oops.
shouldbebar = next(it)
Hooks aren't callback functions, they're functions that take callback functions. apparently this is breaking python. The naming convention is just so the linter can identify hooks, they're not magic.
def react_to_stuff(func, var):
orig = var.copy()
def monitor():
while True:
sleep 2
if var != orig:
orig = var.copy()
func(var)
t = Thread(target=monitor)
t.start()
stuff = "Hello"
react_to_stuff(lambda x: print(x), stuff)
Nothing is stopping you from putting useState in an if statement. You just have to be careful since it's an "iterator." For example if you put it in an if branch you will want to also use it in the else branch so "next" is called the same number of times.
Like I really don’t know how to explain this any clearer.
* React stores the state for your hooks in a list which is iterable.
* useBlah is just a normal function that internally calls next() on that list to get the next hook state which is why order matters.
* React checks that the iteratior on the list is at the end to see if you’ve consumed all the hooks and throws an error if not because it’s indicative of a bug in your code.
Like at this point the only thing I can recommend is try writing a toy implementation of hooks and see that they’re not magic, they’re just normal JS, and that the restrictions flow naturally from the implementation.
Like why do you want so bad for hooks to be weird?
I guess we have very different definitions of "semantics" then. Rspec is wild but it's still plain Ruby. I'll give you that it's not idiomatic and it comes with some unusual restrictions on its use but libraries have been doing forever, I guess I'm just used to "you have to call this function to init the lib", "this function has to come after this", "you must call the cleanup macro here", "importing this lib monkey-patches these classes."
Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run.
Like it's janky and reaches through layers but it's not up and rewriting your code.