make type system be aware of signals

[opensas]

A breaking change that hasn't receives as much publicity as I would have expected is the fact that a component behavior can greatly change depending on how props are passed to it, more specifically, to be reactive the caller has to declare the prop variable with $state

so you can't really rely on the prop being reactive, there's no way (that I know) to make sure it is reactive, and typescript knows nothing about it.

I just stumbled upon this example from deno's fresh (https://www.infoworld.com/article/3523813/intro-to-deno-fresh-a-fresh-take-on-full-stack-javascript.html?ref=dailydev)

islands/Counter.tsx 
import type { Signal } from "@preact/signals";
import { Button } from "../components/Button.tsx";

interface CounterProps {
  count: Signal<number>;
}

export default function Counter(props: CounterProps) {
  return (
    <div class="flex gap-8 py-6">
      <Button onClick={() => props.count.value -= 1}>-1</Button>
      <p class="text-3xl tabular-nums">{props.count}</p>
      <Button onClick={() => props.count.value += 1}>+1</Button>
    </div>
  );
}

I think it would be really helpful to let the type system know that a component is expecting a reactive variable, it would catch a lot of bugs, and it would make our code more clear al explicit.

It would also be useful because it would be more obvious that we are in fact dealing with a proxy.

In svelte 4 we had the $store syntax which made it pretty obvious that we were dealing with a reactive store.

do you think it's possible to do such a thing?

[brunnerh]

Does not work, the signals in Svelte are an invisible implementation detail.
Hence, whether a variable is reactive cannot be encoded in its type.

let reactive = $state(0);
let reactive_trust_me = reactive; // type is the same, but this is not reactive

See:

• TS Types for Svelte 5 $state reactivity #11546

[opensas]

@brunnerh thanks a lot for your reply

I know what you mean, I'm proposing to change that, and make the type system be aware of the fact that it's a signal

[brunnerh]

It's just not possible consistently - the type cannot encode reactivity for primitives.

This would only work if everything is wrapped in something like a { value } object as with the example you gave (props.count.value rather than props.count).

But this would require massive changes and is just worse in terms of ergonomics for most common cases.

[opensas]

I thought we could do something like

type Signal<T> = T

const val1: Signal<number> = 45

but I tried it on a ts playground and it seems like ts just drops the Signal type

[brunnerh]

Even if that were not the case, it would not work.
The type would be copied on variable assignment, when passing a function argument or returning a value from a function.
None of those would be reactive when using primitives (see my original comment).

[opensas]

thanks for the explanation @brunnerh, I guess that dropping the .value from xxx.value = .... had some hard tradeoffs that, at least I, wasn't aware of, and I can understand why the other frameworks either sticks with that or uses functions to read and update values.
I guess an alternative approach would have been to go that way (either with state.value = xxx or setState(xxx)) and take advantage of the compiler to present it as a plain value = xxx, but I'm sure it would have also presented other issues that I cannot foresee right now.

[david-plugge]

A branded type could solve this!

[brunnerh]

See all the other comments. Reactivity is bound to the variable, not the type.

[david-plugge]

Yes i do know that, but what does that have to do with my suggestion? You can create a branded type for primitives which would definately work here.

[brunnerh]

Types transfer on assignment.
Reactivity does not.
=> The types are lying.

[opensas]

Types transfer on assignment. Reactivity does not. => The types are lying.

Let me see if I got it correct.

I think it all boils down to primitives and objects working very differently in JavaScript, and thus in Svelte too

Here's a svelte 5 repl

primitives are translated to $.set(primitive, $.get(primitive) + 1), while objs can be passsed around with their proxy with them, like this obj.value += 1

the only way I can think we could make sure some Signal type wouldn't get out of sync would be to refrain from using reactive primitives, and pass around objects (like vue's refs) or setter / getter function (like solid). in both cases they would be passed by reference.

Am I right?

[brunnerh]

Correct, commented on that here.

[clearfram3]

This seems to be a failure in the signal implementation—the very type of footgun that v5 was meant to solve.

[opensas]

I think it is a matter of tradeoffs

Svelte team decide to keep the svelte 3 DX (reactiveVar = xxxx) instead of going with something like reactiveVar.value = xxx, but in doing so they introduced important differences with the way you deal with primitives and objects, but most importantly we seem to have lost the possibility of telling the type system about our reactive variables in a reliable way, because when you pass around a reactive primitive variable the reactivity is lost.

I'm not so sure by now if it was the correct decision to take, honestly I wouldn't mind so much having to do something like state.variable = xxx if that's the price to pay for being able to confidently pass it around everywhere without loosing reactivity and also relying on the type system to warn me when I require a reactive variable or not.

[opensas]

but now that I think about it runes are meant to be primitives, so perhaps someone (smarter than me surely) comes around with some Signal<T> library where T is not a primitive value

[david-plugge]

Yes that will most likely be the case. But i do think this is a thing svelte itself should do. Every library will bring its own wrapper and you will end up importing the same code 5 Times in your application. Runes do behave just like JS primitives which is fine, its a language limitation. Svelte should provide a solution for that. Even If its just about a best practice like "primitives can not be passed by reference in js therefore your should do X instead".

[clearfram3]

I think you are both spot on. I am ok with state.var if it clarifies this issue, and I don't want what should be core land functionality being defined in library land.