Allow setup() and <script setup> to return a class instance in the composition API

[MichelJonkman]

As the title says I'd like to allow setup() and <script setup> to return a class instance and use that as the context. This would enable more features of Typescript such as decorators but keep the simplicity of the composition API.

The decorators used are purely used as an example and not meant to be included in the feature request.

<script setup lang="ts">
import {ref, watch} from "vue";

const hidden = ref('This should be hidden');

// Typescript decorators do not work with anonymous classes, so it needs a name
class Example {

    public readonly div = ref<HTMLElement | null>(null);

    constructor() {
        watch(this.div, () => {
            // This would also still work
        });
    }

    public exampleMethod() {
        div.style.backgroundColor = 'red';
    }

    // Decorators could be very easily used for hooks and similar features, these are not part of the feature request as they can be easily created separetely
    @hookMounted
    public exampleHook() {
        // Do things on mounted
    }

    // Also watchers
    @watches(this.div, { immediate: true })
    public exampleWatch() {
        // Do things when this.div changes
    }

}

// Preferably it would simply use return
return new Example();

// Or alternatively using export default
export default new Example();

// Or even using a function
context(new Example());


// Using a simple object for this would also work
return {
    exampleMethod() {
        console.log('foo');
    }
};


// Note that using setup() to return a class instance also does not work
export default {
    setup() {
        return new Example();
    }
}
</script>

<template>
    <div>
        <button @click="exampleMethod()">Example</button>

        <div ref="div">
            Example div
        </div>

        <div>
            <!-- This would not work, as the context is explicitly only the returned object -->
            {{ hidden }}
        </div>
    </div>
</template>

Summary

1. Allow return in <script setup> which would work just like in export default {setup() {}}
2. Allow returning of class instances so that Typescript features such as decorators can be used

vue-facing-decorator also exists which does something similar, but does too much in my opinion and relying on it's support for professional products feels iffy.

I personally do not have enough knowledge of the Vue internals to make a PR request or package for this.

If anyone has any questions or needs clarification feel free to say so!

[MichelJonkman]

The issue with point 2 in my summary is that the instance returned from setup() seems to lose the functions in it's prototype, meaning that the class methods are gone.

[jods4]

What's the relationship with script setup?

It looks like you want class-based components, an idea that has been previously discussed and that doesn't need script setup at all? Just a regular script block that exports a class?

[MichelJonkman]

I specifically don't want methods like "mounted()" being used for the lifecycle hook, data being managed by "data()" en the setup existing in "setup()". By only adding the option for a top level return it'll allow for more flexibility and allow developers to use it however they want.

Of course I can just do:

export default {
    setup() {
        return new Example();
    }
}

At the bottom of the script but that's ugly and unneeded, though in hindsight I should've maybe split this up into 2 separate parts. 1 for the returning a class instance part and 1 for the top level return.

[matthew-dean]

This would be amazing! We have a legacy codebase that uses Knockout (class-based) ViewModels and those have to be bound to the template. I've tried a bunch of different patterns when all I really wanted was this: to be able to use the composition API to define a model. You can (sort of) do it with the Options API but then you have to accept all the awkwardness of the options API.

[jods4]

@MichelJonkman I'm not sure I understand.
This component setup() function is the first, and core, design of Composition API. What "top level return" was it meant as an alternative for?
setup() function returns a state JS object that is bound to the view. An instance of a class is a JS object and works just as well. I experimented with fully class-based components during early Vue 3 betas myself -- it was working alright but eventually the script setup approach had more attractive DX.

[MichelJonkman]

@jods4 When I was testing out if this was viable it wasn't possible to return a class instance. This is because somewhere along the way in the Vue internals it reassigns the properties of the instance to a normal object, effectively stripping away all of the class methods that are in the prototype. That means it only works for properties and like I said, it is possible to copy all the methods within the prototype to the object as properties but that seems very hacky and I'm not sure what unintended consequences that could have.

[matthew-dean]

@jods4 You can do that, but then you're 100% locked into the Options API. It would be nice to have the best of both worlds.

[jods4]

@matthew-dean I think there is confusion: setup() function is Composition API, not Options API.
Do you mean you can't use the "script setup" approach? That's true.

[matthew-dean]

@jods4 Sorry, yes. I think this is confusing naming / designation by Vue. I mean <script setup> vs export default, whatever Vue calls this.

[ahku]

How is this related to Composition API? The class return example seems like an everything-goes options API, with the main benefit being that you can freely tag methods as lifecycle hooks with the help of decorators? Unless I'm missing something, it's more work than just using Composition API as is:

public readonly div = ref<HTMLElement | null>(null);

@watches(this.div, { immediate: true })
    public exampleWatch() {
        // Do things when this.div changes
    }

vs.

const div = ref<HTMLElement | null>(null);
watch(div, () => {}, { immediate: true })

What's the benefit of having to name a watcher and rely on a new custom decorator?

And what's the purpose of the return? Components return by default, don't they? The return seems to be the main thing of interest here?

[ahku]

That condensed example feels disingenuous. That's not how you write classes, but my example is how you write functional programming.

It's not cleaner to me for two reasons: 1) you have to come up with an arbitrary name for the watcher method, and 2) you made up a new keyword for the watch (decorator) hook. Of course, everything seems cleaner if you can name everything the way you want it yourself, but that's subjective.

I still don't see how you leverage the composability of Composition API here. Do you mean like how you can sprinkle primitives (refs) inside class methods?

A real example would be how you consume composables, and how you can easily refactor sections of your code into new composables, which just seems harder/less flexible when you are adhering to a rigid class object structure.

[MichelJonkman]

@jods4 Sadly I don't have the code anymore where I tried all this but as far as I remember it worked perfectly fine

[MichelJonkman]

@ahku Code style is always subjective and to me, the class based approach is much cleaner. It is absolutely fine if we disagree on this as this isn't meant to sway anyone to using this style for their own code, it is meant as a proposal to make Vue more flexible and allow these kinds of patterns.

As for the composables part, I don't really get what you mean with "composable", could you elaborate and/or give an example of what you mean? That way I can give a better response to your question!

[ahku]

If there's something that objective oriented programming is not, it's flexible, but let's agree to disagree.

I think that reading up on how the team arrived at the Composition API approach would give you some insight to its goals.

https://vuejs.org/guide/extras/composition-api-faq.html

About composables:
https://vuejs.org/guide/reusability/composables.html#what-is-a-composable

Here's a library built on composables:
https://vueuse.org/

[MichelJonkman]

@ahku My point on this is, if we're allowed to return class instances we'll have more flexibility as it allows the developer to work however he sees fit. Both OOP and functional programming have situations where they're good and situations where they're not very good, allowing both to be used would allow the developer to choose which they want and which they like better!