More readable api to create variables

[avil13]

• Start Date: 2021-11-20
• Target Major Version: 3.x

Summary

Using a variable with data, to reduce the use of functions.

Avoid having to return an object with options from setup().

Not to import ref() or reactive()

Basic example

{
  setup() {
    // $ - as a suggestion, you can make another name
    this.$.name ='Leo';
    this.$.list = ['Mike', 'Don'];
    this.$.showName = () => alert(this.$.name);
  }
}

Motivation

Importing and using the ref and reactive functions creates a lot of boilerplate.

Also variables, if not specially named, can get lost among the others if the component is large.

This is a suggestion to shorten the boilerplate and make it easier for newcomers to understand.

Also, there will be a place where the data of this component will be stored, similar to the data() function.

Detailed design

Since we use Proxy, all variables that will get here can automatically be made reactive at the creation stage.

// example on native JS
const data = {};

const $data = new Proxy(data, {
    set(target, prop, val) {
        // .... check if "ref" or "reactive" is to be used
        target[prop] = ref(val);
        return true;
    },
    get(target, prop) {
        return toRaw(target[prop])
    }
});

$data.age = 100; // new prop already reactive 

console.log($data.age) // 100
$data.age += 1;
console.log($data.age) // 101

You won't have to import ref, reactive, you can also get rid of the .value syntax for simple types.

{
  setup() {
    const name = ref('Leo');
    console.log(name.value); // 'Leo'
    return {
      name,
    };
  }

  // VS
  setup() {  
    this.$.name = 'Alex';
    console.log(this.$.name); // 'ALex'
  }
}

Same with functions

<template>
  <button @click="showAlert">
    click
  </button>
</template>

<script>
{
  setup() {
    this.$.showAlert = () => alert('Hello world!');
  }
}
</script>

Also from setup it will not be necessary to return the object, because it is already stored in the component.

Adoption strategy

This feature is opt-in. Existing code is unaffected.

[jacekkarczmarczyk]

there is https://v3.vuejs.org/api/sfc-script-setup.html already

[avil13]

Thank you, but the script setup has nothing to do with it.
And relative to the proposed option has no pluses at all, at least not yet found.

• there is no single variable storage
• no access without .value property - for simple types
• still need to use boilerplate - ref('string') reactive({ name: 'Leo' })
• reactive variables, and business logic variables are mixed together.

// BAD
let countOfPerson = ref(5); // reactive
let subscriptionPrice = 10; // constant from back-end
let price = ref(countOfPerson * subscriptionPrice);

// GOOD
this.$.countOfPerson = 5; // reactive
let subscriptionPrice = 10; // constant from back-end
this.$.price = this.$.countOfPerson * subscriptionPrice;

Also, you don't need a special compiler to make this functionality work.
Everything can work directly in the browser.

[ahku]

I have a feeling that you are missing all the context behind the API that the team has arrived at.

Like for example type safety and composability. You solution seem like a blend of both options API and composition API, and might not be that much more intuitive than the former.

[avil13]

I agree that I find the Composition API hard to accept.

The proposed option is a symbiosis of "options-api" and "composition api".

The Composition API looks good for "Hello world", but in practice, you can't keep everything in small functions.

The developer has more to do with the inner workings of Vue than with what needs to be done to get the job done.

And if options-api isn't deprecated, why not take the best of both to make it more convenient for the developer. I think his experience is much more valuable.

Typing can be implemented very cheaply, for example like this, and it will not affect JS developers in any way:

interface Data {
  name: string;
  age: number;
}

export default {
  setup<Data>() {
    this.$.name = 'Leo';
    this.$.age = 14;
  }
}

I've seen setup and composition-api as an extension of functionality all along. So did all the colleagues I talked to.

And for me it would have been normal syntax like:

export default {
  setup() {
    this.$.name = 'Leo';
  },
  methods: {
    showAlert() {
      alert(this.$.name);
    },
  },
}

[ahku]

Composition API can indeed be annoying with the .value issue, but I'm sorry, I fail to see what your proposal aims to solve that hasn't been solved better with the Options API already.

With Composition API you can bundle groups of state, methods and life cycle stages,etc into reusable functions which can be combined, composed in a setup context. Your proposal is just the Options API with a magic $ state, that is just one more way to define data that needs to be documented.

[avil13]

With my suggestion, I wanted to offer a solution to the boilerplate problem.
And the fact that I have to write more code for Vue - than for the customer.
He feeds me, after all))).

But I agree with you. Thank you for your reply.

[leopiccionia]

1. It's not clear how it's a significant improvement over Options API. It looks like a mix between data and created, but with inferior type inference.

2. It shouldn't be named setup, because it's totally different from Composition API and would cause confusion.

3. It's missing context e.g. the difference between methods and computed properties, or the semantics with async/await. I think the proposal needs some non-trivial examples.

4. As the proposal stands, it's technically a breaking change, because this.$ already exists.

[leopiccionia]

Now thinking, reactive in Vue 3 is powerful enough to emulate this proposal with minimal changes -- if you don't care about proper type inference.

As the object returned by data function in Options API is wrapped in reactive, I think combining it with created hook is enough to implement a proof-of-concept 100% in userland.

Please notice that it uses this.S instead of this.$, because keys starting with $ or _ are reserved.

https://codesandbox.io/s/this-ux95o

---

I still prefer Composition API over it (especially with ref sugar), though.