4 ms·
Svelte changes the semantics of your code. It's great to show off to-do apps and simple examples. But I'd be very wary of buying into a framework that relied
by nightski 5y ago
Svelte changes the semantics of your code. It's great to show off to-do apps and simple examples. But I'd be very wary of buying into a framework that relied on compiler modifications to the semantics of code to make it work. I'm also not a fan of pub-sub style change notifications. It's hard to reason about what a change in state is going to cause since you don't know what's subscribed.
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).
- dmitriid 5y ago> Svelte changes the semantics of your code. So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.
- Spivak 5y agoEhh 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.
- dmitriid 5y ago> 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.
- charcircuit 5y agoNothing 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.
- Osiris 5y agoIn my experience I get a React error if the number of hooks changes between renders, meaning you can't have hooks in a conditional.
- dmitriid 5y agoSo, let me get this straight. - 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 ;)
- Spivak 5y agoLike 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?
- dmitriid 5y ago> is just a normal function that 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 https://news.ycombinator.com/item?id=30801466
- deleted 5y ago[deleted]