I just don't know, svelte feels way too similar to the "magic" of knockout and angular 1.0 when looking at the output... Something I got burnt by with weird edge cases of update loops or desync.
Svelte might have that all reasoned out though, in which case the harder separation of logic and view is the only stickler for me, and transpiling JSX into svelte would be interesting to see.
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).
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."
You can implement a hooks like interface in an afternoon. I don’t think I could do the same for Svelte’s compiler-oriented approach. Using a compiler means that Svelte is essentially a dialect of EcmaScript, which appears to be mutually intelligible but isn’t always. React used a compiler for JSX which also introduced a dialect, but JSX is optional and very straightforward sugar for a simple function call. The Svelte dialect is not so simple.
> Using a compiler means that Svelte is essentially a dialect of EcmaScript
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.
Exactly, I don't get the React is just Javascript. It's not. You're tied to React just as much as Svelte or anything else. The Facebook propaganda machine is clever I will say.
There’s a wide difference between learning the semantics of an API and learning the semantics of a custom language with a compiler. There are alternate implementations of the React API, like Preact. The semantics of the React API might be complex, but you could implement them in essentially any programming language with function pointers and variable length arrays. You can’t say the same thing for Svelte; which we know is impossible to implement in pure JavaScript, which is why it needs a compiler. This is all anyone in this thread is arguing - it’s an argument about semantics but for some kinds of environments semantics are very important.
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.
Yes and no. They definitely push the boundaries, and the framework imposes certain extra restrictions on how it wants you to use them, and they warp your normal intuitions a bit. But at the end of the day they are just function calls. They don't compile down to some other sort of construct with totally different language semantics.
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.
Yes, they push the boundaries and essentially create a DSL with its own rules that do change semantics of the language. Not as drastically as a custom compiler, but they still do.
A fair point, and I haven't dove into react's inner workings to see how the sausage (I was more discussing the compiled code of the app), but one can reason "how" hooks work after observing them.
- 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".
Honestly they are weird, but I can reason about them with a "good enough" mental model to get paid.
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?
Agree with you completely - hooks really aren't magical at all. The only thing that's "magical" is that React takes hook data and embeds it somewhere in the component instance behind the scene.. something that also necessarily must happen with class components. The state has to live somewhere.
I'm always confused by this comment about hooks. You can sus out the basics of how hooks work under the hood by just looking at their relatively simple rules that govern their usage. More from Dan Abramov: https://medium.com/@dan_abramov/making-sense-of-react-hooks-...
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/)
Svelte might have that all reasoned out though, in which case the harder separation of logic and view is the only stickler for me, and transpiling JSX into svelte would be interesting to see.