Portability of runes

[jonoasan]

Opinion
Sveltes runes system does not provide transparency on whether a variable is reactive or not. This is especially problematic when working with state passed between files and components as it is very easy to drop reactivity through for example decomposition or variable assignments. It is also an issue when consuming 3rd party packages as the only way to know whether a value is reactive or not is to read documentation that hopefully describes this. This is a known issue but it does not seem to be actively worked on at the moment afaik.

Sveltes $state is syntactically similar to reactive() in vue and shares some of its limitations. in vue, the main, and recommended way to declare reactivity is with ref(). this always return an object with a ".value" key that contains the reactive state. This can be implemented manually in svelte, however i think there is a need to standardize this pattern in svelte itself so that 3rd party packages can share a common syntax across the ecosystem.

As a test, i made a simple typescript implementation of a state$() function (note: state$ != $state) that returns a StateRune class, where the '$' key contains the reactive value. Copy it and try it out! This makes it crystal clear when passing the variable between files that it is a reactive value, and that the reactivity is preserved.

// simple state
const counter = state$()
const increment = () => {
	counter.$++
}

// example hook
export const useCounter = () => {
	const count = state$(0);

	const increment = () => {
		count.$ += 1;
	};

	const decrement = () => {
		count.$ -= 1;
	};

	return {
		count: readonly$(count),
		increment,
		decrement,
	};
}

interface Rune<T> {
	$: T;
}

export class StateRune<T> implements Rune<T> {
	private state;

	constructor(value: T) {
		this.state = $state(value);
	}

	get $(): T {
		return this.state;
	}

	set $(newValue: T) {
		this.state = newValue;
	}
}
export const state$ = <T>(value: T) => {
	return new StateRune<T>(value);
};

export class DerivedRune<T> implements Rune<T> {
	private derived;

	constructor(derivedFn: () => T) {
		this.derived = $derived.by(derivedFn);
	}

	get $(): T {
		return this.derived;
	}
}
export const derived$ = <T>(derivedFn: () => T) => {
	return new DerivedRune<T>(derivedFn);
};

export class ReadonlyRune<T> implements Rune<T> {
	private readonly value;

	constructor(value: Rune<T>) {
		this.value = value;
	}

	get $(): T {
		return this.value.$;
	}
}

export const readonly$ = <T>(value: Rune<T>) => {
	return new ReadonlyRune(value);
};

Since this is obviously trivial to implement yourself, you could make the argument that it is not needed as a part of svelte itself, but i think the need is rather to create a standardized way on how to use runes in a portable way in the svelte ecosystem. An actual implementation should therefore be called something like $ref instead of state$. Both $ref and $state runes could be supported in parallel as they cover somewhat different needs/patterns.

So what are your thoughts? Is there a need for this or are there more idiomatic ways to achieve this already?

[brunnerh]

See also this comment and related issues.

[jonoasan]

Thanks! Thats a year old comment though, and it would be interesting to hear the current take on this. have any patterns emerged organically? is it not considered an issue? It feels odd to see the "...for the cases where you need this (which I honestly don't expect to be all that frequent)". Personally i favor clear, readable typing far above slightly more concise syntax, so i need this all the time.

[jonoasan]

Also, i don't see the discussion being around type safety there. We can't track wether a value is reactive or not with types, but this way at least we can wrap it in a class that we know contain reactive state.

[brunnerh]

Not sure if there are any strongly established patterns.

By now there also are some reactive wrappers with a current property in the Svelte base package, e.g. MediaQuery.

Though for read-only reactive state, some people just use functions: () => localStateVar.