More switch-like Switch

[svicalifornia]

As currently implemented in Solid.js, Switch requires invoking signal/memo/props functions for each case. From the Solid.js docs:

<Switch fallback={<p>{x()} is between 5 and 10</p>}>
  <Match when={x() > 10}>
    <p>{x()} is greater than 10</p>
  </Match>
  <Match when={5 > x()}>
    <p>{x()} is less than 5</p>
  </Match>
</Switch>

The (signal?) function x get called as many as three times — once for each Match and again for the fallback.

In most programming languages, the primary benefit of switch is to write and evaluate an expression once and then compare it to multiple potential values without needing to repeat that expression again. It would be great if Solid's Switch could provide the same benefit.

This could be accomplished by adding an optional value attribute to Switch, in which to evaluate the switch expression — if that attribute is provided, then treat nested Match tags as explicit values to be matched by equality, e.g.:

<Switch value={x()} fallback={<SomeDefaultComponent />}>
  <Match value={1}><StepOne /></Match>
  <Match value={2}><StepTwo /></Match>
  <Match value={3}><StepThree /></Match>
</Switch>

[mokeyish]

Is this better? fallback={<SomeDefaultComponent />} is suitable for simple.

<Switch value={x()} >
  <Match value={1}><StepOne /></Match>
  <Match value={2}><StepTwo /></Match>
  <Default>
       <SomeDefaultComponent />
       // lots of complex component.
</Default>
</Switch>

[svicalifornia]

Yes, I agree that a <Default> component would be nice, and I was going to propose that also. However, I didn't want that to distract from the core issue of my current proposal, which is for <Switch> to behave (optionally) like a traditional switch and make equality comparisons to a value computed once in the Switch value attribute.

[ryansolid]

Generally speaking because of how widely shipped the components are we can't break them or really change their behavior too far outside of a major release. Which why I often direct people to solid-primitives to try out these sorts of ideas.

The one benefit the current control flow has is it gives us our mutually exclusive conditionals also acting as if/elseif which allows for it to cover more ground with a single value evaluation. Of course there are ergonomics to consider and we've added a few control flow to solid-primitives like Keyed, so this might be a great place to test the idea.

[svicalifornia]

I'll checked out Keyed. However, I want to emphasize again that I did not suggest changing the current behavior, but instead adding an alternative behavior that would be triggered by specifying a value attribute (not currently used) on Switch.