If you think Svelte is magic, wait until you see how hooks work.
With hooks at least I am able to have a mental model around what happens when I call a change function since it flows top down (instead of bottom up).
So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.
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.
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.
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)
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)On "it's iterators actually", I have a response to a sibling comment here: https://news.ycombinator.com/item?id=30799543
- These are "just function calls"
- Except they are "iterators"
- Except if you have them in a conditional, you must provide an `else` branch so that `next` is called the same number of times
None of this is in the semantics of the language where I don't have to provide an else branch to an iterator, and function calls are not iterators ;)
* 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?
you keep showing isn't a normal function :)
> Like why do you want so bad for hooks to be weird?
I don't want them to be weird. They are weird already. https://news.ycombinator.com/item?id=30801466
So are hooks. The fact that you can't put regular function calls (which hooks look like) in an if statement, or have to provide custom "dependency lists" to some of them, or that data returned from them suddenly re-renders (aka calls again) the function they are in tells you that this is no longer regular Javascript.
I’ve helped teams pilot out of own-the-world frameworks like Backbone and Rails before (both of which substantially distort the runtime they’re embedded in); but it was much harder to deal with Backbone + Coffeescript together. For Backbone w/ vanilla JS or Rails, we could use standard static analysis tools, Coffeescript added a big extra wrinkle to our migration.
There's a fundamental difference between a framework that takes your code and does weird things with it, vs a framework that rewrites the semantics of your code out from under you.
- They're tied to the lifecycle of the component, so they must reach "up" into whatever just called our component function.
- They do not like being moved about/conditionally executed, so hook's likely use an array for metadata storage and position rather than needing explicit "hook keys".
I've no clue what svelte does behind the scenes, much the same way as I can't reckon what WASM or assembly do. So I guess I just have to blindly trust the compiler?
I think they are actually _more_ explicit than classes about how the state is stored. IMO `this` in class based components isn't as straightforward (e.g. https://overreacted.io/why-do-we-write-super-props/)