Export ReactiveValue type

[peterkogo]

Describe the problem

Inside my library, I am currently trying to align the return types of my (user-facing) functions that return reactive values.
I adopted the standard set by svelte/reactivity of returning { current: value }. I see that internally this is achieved through ReactiveValue which also results in the return type ReactiveValue<T>.

Describe the proposed solution

Instead of me creating a very similar type - would it make sense to just export a ReactiveValue type? Maybe this would also promote some consistency across projects, as of today there is no standard on this topic. (you are free to use .current, .value, .ref...)

Importance

nice to have

[rChaoz]

I think there are multiple issues here, and this is why this is left up to the user:

1. The value may or may not be a proxy - the current property may be deep $state proxy, watched by $effects, in which case it is OK to mutate it directly, while other times the setter of current does something, in which case it is not ok to mutate the object
2. In the latter case, the object might have get and set functions instead, as while state.current.abc = 123 is questionable, nobody will do state.get().abc = 123. It might even have a merge update function or similar, like state.update({ abc = 456 }).
3. Read-only reactive values might be represented as a function instead

Since I migrated to Svelte 5 and transformed all of my stores, I used a combination of the above: simple objects with current property, that is explicitly documented as being a proxy so it can be mutated, special State classes with various methods like get, set, update, merge, or the StateFn<T> type that is simply () => T, more of a marker that the returned value is reactive.

Svelte is not opinionated at all, which is why the context system is as basic as it gets, with no type-safety included. I think this falls into the same category and best to also be left unopinionated.

[peterkogo]

Fair enough, I agree that Svelte not being strictly opinionated is good in this case. Also good point about read-only values!

However I'd still argue that a large majority of cases is covered by returning { current } where current can possibly be readonly.