I believe you're referring to $ not being fired when another $ below it updates the variable the first $ subscribes to. This is an expected behavior. In Svelte the order of $ matters to prevent infinite loops.
In this example the second $ won't trigger the first $:
let a = 1;
let b = 1;
$: if (a > 0) { b += 1 }
$: if (b > 0) { a += 1 }
With React's useEffect one can easily falls into the trap of an infinite re-rendering:
let a = 1;
let b = 1;
useEffect(() => {
b += 1;
}, [a]);
useEffect(() => {
a += 1;
}, [b]);
Great framework are supposed to prevent this kind of loophole.
I haven't done much playing around with Svelte so don't have any business injecting myself into this subthread, but your explanation piqued my curiosity.
So basically, reactive blocks are only allowed to run once per tick; if a dependency changes after a block has run, too bad, the block won't run again. That is really shocking to me. (I won't say more due to my inexperience with Svelte...)
This is all triggering my memory, I had forgotten how it actually worked so couldn't explain the issue I was having. But it was related to this exact behavior. I found it so unintuitive and difficult to grasp that I literally abandoned the project and decided to build it from scratch in React.
It's a shame because it's an otherwise lovely framework.
I think there’s a strong argument to be made here that the actual code in this scenario is flawed.
What Svelte is doing is simply covering up the flaws in your code by short circuiting an infinite loop scenario which has been coded into your app. This will have unexpected side effects, however.
That being said, I think useEffects is far too overloaded in React, and is currently used for completely orthogonal purposes.
At he very least it’s used for the following completely unrelated purposes.
1. Component setup and graceful dismantling.
2. Syncing with external state.
3. Running code specific to a certain prop being changed.
I think the React team would be highly justified if they created a separate hook for #3 at least. Maybe a usePropsChanged hook that is called when one of the props change, and provides an isChanged function that you can pass a prop to, to check if it’s actually changed (I’m sure someone can come up with a better design than I have in the process of writing this comment).
That would be a semantic which would actually allow you to avoid the code flaw that your code above includes, as opposed to brute force papering it over like Svelte appears to do.
Novice react developers reach for useEffect way too often, because they are still thinking in terms of state transitions instead of declarative states. I have spent a lot of time teaching people not to do that. They always end up very happy once they get it, because now they can build complex UIs and have a solid strategy for compartmentalization, which makes bug whack-a-mole go away.
It's not a fault in the framework, it's a fault in their understanding, where they don't know how to implement features in O(N) lines of code instead of O(N^2).
The hint is in the name: you're supposed to think in terms of formal functional Effects that mount and unmount independently and compose orthogonally.
The result will be a code base that remains maintainable even though you've kept on adding more nuanced features over months and months.
Also, your snippet doesn't cause an infinite loop at all because modifying local variables does not trigger a rerender. If you had written setA / setB, sure, it would... but I think this perfectly illustrates the explicit vs implicit distinction.
Great frameworks don't trap developers in local maxima.
I think what you are describing looks a lot like what the Svelte team is trying to achieve with the reactive assignments "$:"
A couple years ago, that feature used to work similar as useEffect, so I got used to use it for transitions, and now is biting my ass because the Svelte team are breaking my transition use-cases
I used to use "$" like useEffect, but now I don't know how to use it anymore
And Svelte still bites my intuitions when dealing with complex objects, most of the times I've manage solve it by separating the code into multiple components, but it's not clear why that happens
If you're not into selfies, you may ignore the fact that your smartphone has a front facing camera. It may not be for you, but other people do use it.
HN is a tech community, which means there're many programmers here. Some people may use X and also contribute to X, or at least want to dig into the source code.
For example, since I'm a Rust programmer and not an R programmer, I'm more interested in "A fast query engine written in Rust" than "A fast query engine written in R". There're benefits of using a program written in a language you're familiar with. One of them is when you find a bug you can dig into the source code, post an issue which point out which code might cause the bug, better yet post a PR. Instead of "Please help, X failed to do Y."
- On advanced query: 3rd, 6th, 6th, 4th (up 1), - (out of memory).
> The databases (and spark) will have to read from disk. They have no chance of competing with anything that's reading from ram, no matter how slow it is.
Not true. Upon quick peek on the bench code, ClickHouse and Spark use in-memory table. I assume other engines too.
