V Switch Case and Default added to core

[louiss0]

Start Date: 2023/1/23

• Target Major Version: (3.x)
• Reference Issues: (fill in existing related issues, if any)
• Implementation PR: (leave this empty)

Summary

This is a set of directives that allow the user to evaluate a condition based on whether or not it is a string number or array. The first one is called v-switch it takes away child nodes based on the value passed to it. The second one is called v-case is a directive that allows the user to send values for v-switch to find. The last one is v-default. It's the one that will render a DOM node if v-switch finds none from the values from v-case.

Here is the link to a prototype that I created to make life easier https://stackblitz.com/edit/vitejs-vite-b6zaq8. It's in the App.vue file.

Basic example

If the proposal involves a new or changed API, include a basic code example.
Omit this section if it's not applicable.

// This directive looks for the values in the case directives. 
<div v-switch="7">

	// This directive injects values for v-switch to use
    <div v-case="3">Three</div>

    <div v-case="0">Ten</div>

    <div v-case="3">Six</div>

    <div v-case="9">NIne</div>

	This tells v-switch to render this div if 
	any of the values sent to switch to use are not found.
    <div v-default>This is the default</div>

  </div>

Motivation

Why are we doing this?

Having to use if statements for situations where you just want to know if a value is a certain value is tedious? When you have to use if statements to find out whether or not a value is in certain set of values you have to write \=== all the time. Giving developers a strict and type safe way of evaluating strings will save time and reduce verbosity.

What use cases does it support?

It support's cases where you need to find out if a string is of a certain value or a variable is a number. There are times where we use certain keywords to decide whether or not to render UI.
For instance lets say that we are loading information from a Promise. The state could be pending, resolved , rejected. The code to represent rendering UI based on this would be like this.

<script setup>

const promiseState = ref('pending')

</script>
/* 
	I have to write the promiseState variable repeatedly.
	I have to write the equal sign repeatedly.
*/
<div v-if="promiseState === 'pending'" ></div>

<div v-else-if="promiseState === 'resolved'"></div>

<div v-else-if="promiseState === 'rejected'">
</div>

What is the expected outcome?

The community will be able to write code where a UI is rendered based on a small set of values in a simple and a reusable way.

Detailed design

This proposal involves three compile-time directives that are used for rendering. v-switch v-case and v-default The v-switch directive takes in a string or a number then looks at all of it's rendered children. If one of them contains a value that was sent to the switch directive the switch directive will preserve that element if not it will destroy it. The v-case directives are responsible for sending values for v-switch to use the way this happens is the v-case statement sets a property Symbol('v-case') inside of the element's dataset as a key with the value being the one that was passed to the directive. The v-switch directive find the value for each of them inside of the dataset. What v-default does is put a Symbol('v-default') as a key inside of it's elements dataset with the value of true.

V-switch

<div v-switch="2"></div>

V switch does the following things

• Throws an error if any of it's children don't have a case statement inside of it or a default one
• It takes in a value then evaluates the values in each case statement by using strict equality not the normal one.

V-case

<div v-switch="2">
<div v-case="5">I'm five</div>
</div>

V case does the following things

• Throws an error if any of it's siblings don't have a case statement inside of it or a default one
• Throws an error if it doesn't have a parent element

V-default

<div v-switch="2">
<div v-default>I'm the default</div>
</div>

V default does the following things

• Throws an error if there is a value passed to it
• Throws an error if any of it's previous siblings don't have a case statement inside of it
• It is attached to element without a parent element.

How it works with typescript

I don't know how the Volar works but volar does support the use of conditional's that emulate typescript features. The way v-switch would work is the same way that switch works in typescript. It would have the same features except in the template instead of in the DOM. If a union type is put inside of the switch statement the user will be forced to put it each value in the union in the case statements and write as many cases as there are in the union types.

This switch directive will work like this

Drawbacks

A breaking change is considered to because to a change that changes software regardless of whether or not something is removed or not? But developers will have to learn another alternative to evaluating conditions. Teachers of Vue will have to add new syntax to their curriculum.

Alternatives

What is the impact of not doing this?

People will have to write verbose if statements in order to evaluate values with a certain set of constraints.

Adoption strategy

This change is simply additive it will not force any changes to the ecosystem.

Unresolved questions

How will types be inferred I don't how how that would work?

Can other Data Structures be supported as well?

[jods4]

The detailed design is based on v-switch being a directive.
That would exhibit a different behaviour compared to the "equivalent" v-if in Motivation section.
v-if is compiler magic that becomes an actual if in the rendering function: so when the condition is falsy, no code inside that branch (expressions, directives, etc.) runs.
If this RFC is accepted, I think it should be a new directive understood by compiler and turned into actual render function code, rather than rendering everything and then trying to fix up the (v)DOM.

Limiting values to string and number seems restrictive. Why do you exclude bigint, null, undefined or symbol? They could be useful. It would seem natural that such a compilation directive mimics the JS switch statement, which actually accepts any expression, even objects.

[louiss0]

I just want it to exist. Don't take the implementation too seriously. I don't know enough about Vue to do a deeper version. The code that I wrote here is just a prototype. I saw no value it supporting data structures that use key-value pairs but if there are cases for it then I don't mind supporting them.

[louiss0]

The detailed design is based on v-switch being a directive. That would exhibit a different behaviour compared to the "equivalent" v-if in Motivation section. v-if is compiler magic that becomes an actual if in the rendering function: so when the condition is falsy, no code inside that branch (expressions, directives, etc.) runs. If this RFC is accepted, I think it should be a new directive understood by compiler and turned into actual render function code, rather than rendering everything and then trying to fix up the (v)DOM.

Limiting values to string and number seems restrictive. Why do you exclude bigint, null, undefined or symbol? They could be useful. It would seem natural that such a compilation directive mimics the JS switch statement, which actually accepts any expression, even objects.

Well when I created the switch statement I wanted to only restrict it to only values not data structures and thought that there is no point in it supporting other kinds of values. I forgot that big-int even existed. I thought this version would be the realistic one. I have to change this RFC now. Thanks for pointing that out to me.

[nyambe]

How would you go about debugging this? also how would it work with typescript?

[Oktogazh]

https://github.com/lmiller1990/v-switch/

[upsiflu]

A good reference would be the coming JS pattern matching syntax:

match (myVariable) {
  when ["foo", {bar}]: "Blue";
  when ["foo", _ ]: "Red";
  when []: "Yellow";
  default: "Black";
}

It has two main motivations:

1. No more writing tedious if-else statements
2. Destructuring is cool, it can be used to match values and types

Very nice description of the proposal: https://github.com/tc39/proposal-pattern-matching

The proposal explains the problems with the existing switch statement in JS. I agree with the authors that switch is a pain in the A and that we need actual pattern matching with sensible lexical scoping.

Vue should definitely implement a directive mirroring match, just like v-if mirrors JS if. The correspondence goes quite deep. For example, inside a <template v-if="typeof x === 'string'">, the compiler knows that x is a string, just like if you write typeof x === 'string' ? x.split(' ') in TS. The same type narrowing and scoping will be implemented for patterns, and vue-tsc can use that. As a bonus, such a directive would allow the user to destructure anything inside a limited scope in the template, as in

<template v-when:myArray="[head, ...tail]">
  Head: {{ head }}
</template>

Control flow is one of the areas where I feel the template syntax limiting. It's hard to express components that vary over time because there are only v-if and v-for. I don't like marshalling all my data in the <script setup> before I can use it in the <template> because then I often have to scroll up and down. I like how v-slot={ ... } can provide very limited lexical scopes.

The same proposal also describes a new operator is.
It can be combined with v-if to form more precise conditions. Then we'd not need a new directive.

<A v-if="myObject is {let something}">
   {{ something }}
</A>
<B v-else> ...

The is operator can also be used in for loops, and I imagine it would work just the same in v-for to make ranged selections.

[Anoesj]

First thoughts after reading the proposal: while it'll take a long time for this to mature and reach some form of consensus, this looks very promising. It definitely has the potential to fix multiple shortcomings of Vue's template syntax at once: switch-like patterns and creating local variables in a template.