[apd_]

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.

[jcheng]

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.

https://github.com/sveltejs/svelte/issues/6730

https://github.com/sveltejs/svelte/issues/6732

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...)

[danielvaughn]

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.

[addicted]

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.

[unconed]

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.

[uxcolumbo]

> because they are still thinking in terms of state transitions instead of declarative states

Do you have any links where I could read more about this? Or examples?

[madacol]

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

[madacol]

$ has a looot of gotchas, under some conditions, the reactivity climps up the dependency tree. E.g. https://github.com/sveltejs/svelte/issues/4933

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

[phist_mcgee]

What happens if you do want effects to update each other's dependencies, but only conditionally? eg. A certain number of cascading updates?