Signals are troublesome with Typescript

[stefnotch]

Lots of typical Typescript code uses union types. For example, when a value can either be a number, or can be null. number | null.
Or it can be a discriminated union, see #1575 (comment)

Examples

Here is a very simplistic example

let count = null as number | null;

const increment = () => { count = (count ?? 0) + 1; }; 

if(count != null) {
  // notice how Typescript is happy, because it knows that count is not null
  console.log("next value" + (count + 1));
}

Attempting to do the same using a signal and the Show tag is painful though.

export default function Counter() {
  const [count, setCount] = createSignal<number|null>(null);

  return (
    <button class="increment" onClick={() => setCount((count() ?? 0) + 1)}>
      Clicks: {count()}
      <Show when={count() != null}>
{/* Typescript complains here, because it cannot figure out that count() won't be null */}
        next value will be {count() + 1}
      </Show>
    </button>
  );
}

This is mostly a toy example to illustrate my point. (The documentation also uses that toy example https://www.solidjs.com/guides/typescript#control-flow-narrowing ) This one can be worked around, but I think it becomes very painful once one writes anything bigger.
e.g. Someone else attempted to use discriminated unions and didn't find any good solutions #1527 (comment)
e.g. Nested properties don't have an easy way of being dealt with.

Why?

I feel like this is a Typescript limitation, made worse by SolidJS's signal API design choice.

As in, when using props instead of signals, it might become possible to use type assertions to properly type the Show tag ( microsoft/TypeScript#40562 ).

But, this is much harder with a signal. A signal has a getter, which simply a function. However, a function does not have to return the same value every time, which means that Typescript cannot narrow its return type.

e.g.

  const [count, setCount] = createSignal<number|null>(null);

  if(count() != null) {
    console.log("next value" + (count() + 1));
  }

The workaround there is to introduce a local variable, but of course that doesn't work in JSX.

[stefnotch]

Regarding the Switch and Match, here's a simple example that doesn't appear to have a good workaround.

type User =
  | { tag: "anonymous" }
  | { tag: "user"; name: string }
  | { tag: "admin"; email: string };

const ViewA = (props: User) => (
  <Switch>
    <Match when={props.tag === "anonymous"}>Hello stranger!</Match>
    <Match when={props.tag === "user"}>
{/* Typescript errors here */}
      Hello {props.name}
    </Match>
    <Match when={props.tag === "admin"}>
{/* and another Typescript error here */}
      Hello admin at {props.email}
    </Match>
  </Switch>
);

[stefnotch]

@ryansolid I do apologise for the ping, but I feel like it would be important to raise this issue as early as possible. After all, fixing potentially major issues early seems like the easiest option. Limitations like these are blocking me from using Solid with Typescript.

Is there a plan on how to eventually deal with this? e.g.

• Opening an issue with the lovely Typescript team as early as possible
• Investigating different API design choices
• Having a Solid language server

[ryansolid]

1. I tried to bring up my concern around idepotent functions with TS people I knew and they basically told me it was highly unlikely they'd ever be able to implement that in a reasonable way. I brought up how getters are basically broken the opposite way and they basically consider it a choose your battles thing. To be fair I'd still write an issue but I lack the TS knowledge to even write up what I want it to do. But if this can be fixed the rest can be improved.

2. Having TS change API is hard... Mostly that there are reasons for the API the way it is. Reasons why for composition I don't just disfavor . value because of some opinion. We've talked about this at length before. I have a whole stream about it. But short of it is we want to support functions as they are instead of forcing wrappers on people.

Similarly with JSX we want our control flow to be composable. I'm not sure any automatic analysis could ever handle:

<MyIf condition={something()}>
  <MaybeShown />
</MyIf>

Now we support ternaries and I could see a reality where switch or native control flow inside JSX blocks could be processed but it would have limited application because it wouldn't be understood outside of the immediate scope. Things like do expressions might make that possible but it would be limited.

The function form of <Show> and <For> are at least helpful. For is fine atleast. <Show> is still tricky. Switch/Match I suppose is a but harder to get the same benefit. I am open to designing some different control flow around Switch/Match. I think though for any of these to work the idepontent functions need to come first. The fact that Angular uses functions for Signals (again for good reason) too I'm hoping helps this.

3. I mean that's a whole other thing and I'm not sure short of specializing tags this even helps outside of like making our own JSX fork. It's also an insane amount of work.

---

If someone wants to help frame a proposal to TS for what I'm calling idepotent functions I will push it through all my channels to draw attention to it.

[atk]

You can help yourself with a guard function:

const isDef = <T extends any>(accessor: Accessor<T | undefined>): accessor is Accessor<T> =>
  accessor() !== undefined;

if (isDef(count)) {
  // herein, count will be handled as () => number
}

[flevi29]

Is there an issue about this or a discussion open on TypeScript? I couldn't find any. Are they aware of this issue? I'm not sure they are.
This issue has come up in Angular as well: angular/angular#49161

[stefnotch]

I'm not aware of a relevant upstream Typescript issue. @flevi29 It would be lovely if you could open one, to make them aware of one current issue in the ecosystem.

Although, chances are that the only short term solution is to adopt Vue.js-like signals. That is, not being function based and instead having a .value getter and setter.

Long term solutions could have many shapes and forms.

[flevi29]

I'm not sure if TypeScript will ever come up with a solution to this. Getters and setters path might as well be non-null assertion path in terms of type safety, but I guess at least you have discriminated unions and more comfort. I don't get it, TypeScript is sometimes hell bent on type safety, and other times we get stuff like this:

class Asd {
  number = 0;

  get value(): number | null {
    this.number += 1;
    const variant = this.number % 2;
    const retval = variant === 0 ? null : this.number;
    console.log("called", variant, retval)
    return retval;
  }
}

const asd = new Asd();

for (let i = 0; i < 10; i += 1) {
  if (asd.value !== null) {
    const wrong: number = asd.value;
    console.log(wrong);
  }
}

[stefnotch]

Turns out that I was wrong. Apparently even a world where Solid has an API with a .value getter and setter wouldn't work, due to how JSX works.

https://playground.solidjs.com/anonymous/e428e57a-1c0b-44fe-9450-f70eeacc57a7

[stefnotch]

It might just work in Angular-land though angular/angular#49161 (comment)