Improve Visibility of Reactive Variables

[plasmatech8]

Description

This is most relevant to Svelte 5, but is also applicable to prior versions.

Reactive variables and non-reactive variables are co-located in your code when writing a Svelte app.

This may cause some minor inconvenience when you need to check the implementation to determine whether a variable is reactive or not.

This may also be inconvenient for beginners who might not know what is reactivity is.

For example:

• If you have a store, and overlook using $myStore subscribe syntax, it will not be reactive.
• (in Svelte 5) Beginners may not be able to tell the difference between $state and let
• (in Svelte 5) If you create a store, but overlook using getters/setters - the result is a non-reactive variable. To figure out if the store is truly reactive, you must dig into the function to see if the store was written properly. You may not know if a property of an object is reactive, or if the object is a store at all (e.g. window/document/package-objects).

Proposed solution

Reactive variables (state/derived/stores) visual cues:

• Use underline to indicate that this variable is reactive.

(Additional possibilities/features)

Show side effects of a state assignment =:

• An iInline text/annotation is appended to end of line containing the assignment (i.e. in the Error Lens VSCode extension) which shows names of other variables which are affected by the assignment.

Show dependencies of a reactive variable:

• Hover over the variable to display a pop-up which show a list of variable names which would cause this variable to change/react

Alternatives

Other ways to visually indicate reactive variables:

• Text color (*)
• Color highlight
• Inline text/annotation
• Hover popup info

Additional Information, eg. Screenshots

A visual distinction between reactive and non-reactive variables could add clarity and improve elegance in the sense of having reactive/non-reactive variables co-located.

Note: reddit post

Below shows an example in Svelte 5 (as-of the current early preview) of what it could look like before and after adding proposed features:

[opensas]

Perhaps, more than visibility, we could use a Reactive<T> type to mark a variable as being reactive

so $state('hello') would return a Reactive<string> instead of a plain string

that way we could also state that a prop (which are not reactive by default) are required to be reactive, just like we did when we needed a Writable<T> with stores

[brunnerh]

Types do not work, they would falsely transfer on assignment to non-reactive variables (like a const without $derived or when passed to a function).

[opensas]

Types do not work, they would falsely transfer on assignment to non-reactive variables (like a const without $derived or when passed to a function).

haven't thought about it, it would be great to find a workaround to let the type system be aware of reactive values

[jnilla]

From the docs: https://react.dev/learn/lifecycle-of-reactive-effects#all-variables-declared-in-the-component-body-are-reactive

Quote: Props and state aren’t the only reactive values. Values that you calculate from them are also reactive. If the props or state change, your component will re-render, and the values calculated from them will also change.