docs: clarify effect alternatives section

[benmccann]

A handful of minor cleanups:

• there were two different "do this" / "don't do this" formats. Standardize on the one that's much easier to read
• clarify that callback props are being used (component events no longer exist in Svelte 5)
• rename variable from proxy to facade since it's not a Proxy

[changeset-bot]

⚠️ No Changeset found

Latest commit: 00e7dca

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[svelte-kit-so-good]

The following example in the docs:

let { result_1, result_2 } = $derived.by(() => {
        // ... some lengthy code resulting in
        return {
	        result_1: someValue,
	        result_2: someOtherValue
        };
});

is a very good answer to the question I posed long ago in the Discord, i.e. what to do with the '1-condition-to-many-updates' scenario? Back then neither destructuring $derived, nor $derived with callback was around ... so I'm glad that's settled.

Still using $effect might at first seem more flexible to migrators of '$:' ... since there could be many logical branches in the $effect that update different states (i.e. subset of { result_1, ..., result_n }).

You also mention in the docs that in extreme cases you can use untrack inside an $effect ... so that sorta goes against my assumption that it's buggy under the hood to update state in an $effect. Not to beat a dead horse but I wonder if having a $watch-like rune ($effect.some_hopefully_short_property_name) could still be useful ... but still make it clear in the docs that multiple $derived and/or destructured $derived.by should be preferred.

As an aside how would you replicate this Svelte 4 code in Svelte 5 with untracked effect?

let count = 1;
$: if( count > 0) count++

[dummdidumm]

You would need to create an explicit dependencies array and use untrack and tick like this

[svelte-kit-so-good]

You would need to create an explicit dependencies array and use untrack and tick like this

Thanks Simon. Yea I think this example is why I thought of '$watch' ... I vaguely remember someone else use your code (untrack + tick) to do so .. I was going that direction actually before giving up lol.

Not that I find this particular example that useful, but the 'boilerplate inflation' here is quite drastic!

[dummdidumm]

If there are many real world use cases where something like this is the best/only solution to a certain problem, then we maybe can add something like $effect.once_per_tick, but it seems to me like in the vast majority of cases the new behavior is what you want. Also note that the boilerplate-to-logic is drastic in the example, but the function could be inside a library (so you don't write it yourself), and the code will certainly be more than just count++.

[svelte-kit-so-good]

Ah ok so Thiagolino mentioned something along these lines then.