Add Options API / Composition API choice when creating a project

[TheJaredWilcurt]

Many people strongly prefer the Options API and all the benefits it offers over Composition API (most importantly, inherent and enforced organizational structure). Much like all the documentation on the Vue website. Composition API and Options API should be treated equally as a choice.

[laoshaw]

Second this. Vue3 can have a poll for this, we might have more options API users than composition APIs in the end. In my opinion composition API is more complex, leads to spaghetti code etc. Please at least treat them equally.
I have moved to vite, but sadly vite is defaulted to composition api too and it does not provide an option api option either.

[haoqunjiang]

1. You don't need a switch to choose between Options API and Composition API. They are both supported. Just write the component in whatever way you like. Adding an option for this may confuse newcomers and make them think the two styles are mutually exclusive.
2. The default template in this repo contains very minimal JavaScript logic in the components. Almost all are mere imports and defineProps. They are much more concise when written in script setup.

[TheJaredWilcurt]

Just write the component in whatever way you like

Yes, it is not hard to:

• Add in Pinia by hand
• Vite by hand
• re-write the components to Options API by hand
• Add Vue-Router by hand
• Hook up ESLint by hand
• etc.

But the point of a boilerplate is to expedite these redundant setup steps so that you can get to the project part quicker. I 100% disagree on this being a point of confusion for beginners. It is merely a choice, just like how TypeScript is a "Yes/No" choice, but doesn't need to be used in every component. If you word the choice as what default API to use, this infers that you are not locked in to this choice, it is merely going to save you time from having to re-write the boilerplate.

Example:

Project name: ... vue-project
Default Component API: ... Composition / Options
Add TypeScript? ... No / Yes
Add JSX Support? ... No / Yes
Add Vue Router for Single Page Application development? ... No / Yes
Add Pinia for state management? ... No / Yes
Add Vitest for Unit Testing? ... No / Yes
Add Cypress for both Unit and End-to-End testing? ... No / Yes
Add ESLint for code quality? ... No / Yes

[haoqunjiang]

Let's be practical.
Where do you think we can put the Options API boilerplate?

The templates are so minimal that I can't think of any use case of either Options API or Composition API boilerplates.

(Please don't take <script setup> with mere imports and defineProps as a Composition API snippet, they are just syntactic sugars. You can add your own <script> with Options API later in the file or append contents into the <script setup> blocks.)

[laoshaw]

if you have to pick one, I'd think options-api should be the default instead of composition-api.

1. it's what vue2 uses, people are still moving over.
2. many projects do not need do composition api, there are probably more small to mid-sized projects that can work with options-api just fine.
3. options-api seems simpler for beginner, vue's biggest selling point is user friendly, you don't want to take that lightly, especially when you're doing a major upgrade like python2 to python3.
4. few experienced developers favor compositions api, majority users might not feel the same.

[haoqunjiang]

if you have to pick one

I didn't make any choice in this template.
Actually, I've deleted a Composition API example since the first release.

[TheJaredWilcurt]

I appreciate the effort put forth in this repo and civility in responses from both sides. I'm just looking for the time save, and a tool I can recommend to others.

I feel this has some similarities to linting, in that there is much room for opinion and good arguments for many choices, but I can point to my custom linting rules and run one command to "fix" everything to my preference. Unfortunately, there is no tool to do this with Vue's API, I would still be tasked with the manual effort of converting everything over. Which is not something I can easily ask of others if I were to recommend vue-create. There are so many great things about Vue, but the Options API is the main reason I see to recommend it to others. I don't see much point in having a vue-create tool if I can't recommend it to people as a good choice to start their Vue projects because it's missing the most important feature of Vue. Honestly, the Options API approach is the one thing that all other frameworks really need to steal from Vue.

This is why I was requesting the API's be a simple choice, which API it defaults to is irrelevant to me, so long as both are equally easy to chose between. This is the time save I'm looking for, and would give me the confidence to recommend this tool to others, since it would be the same one I use and wouldn't require a bunch of extra explanation of additional steps to get the project ready after using a boilerplate. At that point I might as well just build a competing tool that no one will know about (see: Jest-Serializer-Vue-TJW). I'd rather not go down that rabbit-hole again.

If this is merely an issue with the implementation effort, then I think a better response would be "Open to PRs". Moving the burden of the feature to the community, while not outright forbidding it's addition.

[haoqunjiang]

For god's sake, I'm not arguing which API is better.
My whole point is that such an option doesn't fit into this tool because they are NOT MUTUALLY EXCLUSIVE. You can use BOTH WITH ZERO CONFIGURATION.

The point is, ZERO CONFIGURATION. Then the scaffolding tool shouldn't make users' life harder by forcing them to think about one more feature.

[haoqunjiang]

it is merely going to save you time from having to re-write the boilerplate

You have to re-write the boilerplate anyway. Please, take a look at the scaffolded project.
Do you really start writing your own component by renaming HelloWorld.vue and filling in its <script> block?

We deliberately made the boilerplate components easier to delete to save users some time.
Come on, this is a one-off template. We don't have a vue generate component comp-foo. I don't get the idea of forcing a default component style.

then I think a better response would be "Open to PRs". Moving the burden of the feature to the community, while not outright forbidding it's addition.

Well, I think a well-established convention in the open-source community is to reach a consensus on whether a feature should be added and the general approach to implement before starting coding.

Because coding isn't a burden to maintainers. It's the attention resources that are scarce.
It's already very energy-consuming to engage in a feature discussion.
It would be much much harder to review a pull request IN THE SAME TIME OF discussing the feature.

[TheJaredWilcurt]

I have reviewed the source files, particularly those in the template/code directory. I think this is one of those cases of UX in which a developer makes an assumption about the users based on their own usage, instead of just asking them. Yes, I literally rename the HelloWorld.vue file to what I need and tweak it as I go. Long-term projects are rare. I will use a boilerplate to create one maybe a few times a year. However, I will often (several times a week) spin up a disposable project to test things out, try out libraries, etc. This is the value a boilerplate offers. Sometimes I don't even rename the components, just gut the <template> sections and start adding things into the Options API to try things out. This is especially common on sites like CodeSandbox. However, I do this locally as well, which is were vue-create would be valuable. So having to break that flow, stop, and re-write everything, is just a non-starter.

I don't see a problem with adding a options-api-default/src and options-api-router/src folder that is a duplicate of the existing default/src and router/src but with the Options API already in place. Then offering the option.

Default Component API: ... Composition / Options

This would make a lot of people very happy, myself included. Again, happy to do a PR if it will be accepted.

[laoshaw]

I have reviewed the source files, particularly those in the template/code directory. I think this is one of those cases of UX in which a developer makes an assumption about the users based on their own usage, instead of just asking them. Yes, I literally rename the HelloWorld.vue file to what I need and tweak it as I go. Long-term projects are rare. I will use a boilerplate to create one maybe a few times a year. However, I will often (several times a week) spin up a disposable project to test things out, try out libraries, etc. This is the value a boilerplate offers. Sometimes I don't even rename the components, just gut the <template> sections and start adding things into the Options API to try things out. This is especially common on sites like CodeSandbox. However, I do this locally as well, which is were vue-create would be valuable. So having to break that flow, stop, and re-write everything, is just a non-starter.

I don't see a problem with adding a options-api-default/src and options-api-router/src folder that is a duplicate of the existing default/src and router/src but with the Options API already in place. Then offering the option.

Default Component API: ... Composition / Options

This would make a lot of people very happy, myself included. Again, happy to do a PR if it will be accepted.

can't agree more, it's quite obvious indeed, I really don't get why it is treated this way: you have two APIs, let users pick one is not rocket science, and maybe majority of the users are actually using options api anyway, and it does not like a revamp to add that 'feature' either.

I spin temp vue projects sometimes a few times a day to test out things quick, I since made a patch to convert composition api to options api, why do I need patch it for a starter template a few times a day?

[haoqunjiang]

I spin temp vue projects sometimes a few times a day to test out things quick, I since made a patch to convert composition api to options api, why do I need patch it for a starter template a few times a day?

You don't need to patch anything.

Take the HelloWorld.vue as an example:
After npm init vue@3 it's:

<script setup>
defineProps({
  msg: {
    type: String,
    required: true
  }
})
</script>
<template>
...
</template>

You can prepend or append a script block directly to the file and it still works:

<script>
import { defineComponent } from 'vue';

export default defineComponent({
  data() {
    return {
      foo: 'bar'
    }
  }
})
</script>

<script setup>
defineProps({
  msg: {
    type: String,
    required: true
  }
})
</script>

Of course, defineComponent is optional, so you can simply write:

<script>
export default({
  data() {
    return {
      foo: 'bar'
    }
  }
})
</script>

<script setup>
defineProps({
  msg: {
    type: String,
    required: true
  }
})
</script>

And ideally, there should be a snippet in your IDE/editor that automatically generates the export default defineComponent({}) block for you with a few keystrokes.

---

So basically, you can just ignore the <script setup> blocks here.
Just treat it as a purely presentational component without any <script>s.

---

So I don't think we need to change the template of this tool for your described task. It seems an overkill.

[TheJaredWilcurt]

But that new script block doesn't have a props section, specifically for the prop being passed in, that I may want to modify, using the Options API. Yes.... I can write a new script block.... and yes I can cut & paste the props object into it... and then I can delete the old script block which is now empty. But.... that's the same thing as just re-writing it from scratch, but with extra steps.

I don't know how to explain this again in a different way. Users want the Options API available by default.

• If you see no difference between the two, why not pick the API that has existed in every version of Vue?
• If you find there is value in having the Composition API there by default, then hooray, you understand the same thing we want, just with the other API.
• Are you're afraid changing it to only have Options API by default would get complaints from people that want the Composition API in place by default?
  • If so, there's a solution for that, give people the choice, so everyone is happy, and it saves everyone time.

Again. Happy to make a PR for this.