Add Options API / Composition API choice when creating a project about create-vue HOT 16 CLOSED

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.

from create-vue.

I agree with @sodatea that Composition Api vs Options Api should not be a template choice because it doesn't affect package dependencies. package.json looks the same either way, whereas the other options do change what's included.

Maybe to appease those who want to see Options API examples there could just be an additional component written with Options Api, maybe with just defineComponent and a single prop. This will also show that a project could have both.

from create-vue.

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.

from create-vue.

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.

from create-vue.

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

from create-vue.

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.)

from create-vue.

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.

from create-vue.

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.

from create-vue.

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.

from create-vue.

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.

from create-vue.

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.

from create-vue.

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?

from create-vue.

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.

from create-vue.

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.

from create-vue.

Boilerplate is supposed to make developers and beginners' life easier.

There are simply two APIs, the existing commonly used was unsupported, instead the new one becomes the default.

Even a PR offer for adding the commonly used options-API was rejected outright. I don't get it.

If there must be only one, it should be Options API as it used to be IMHO. Advanced users who prefer Composition API probably does not need boilerplate tools at all.

Vite has the same problem, only Composition code is by default, yes I added Options API by hand each time, but why should I?

from create-vue.

@pholly

I'd view that approach as at least an improvement, however it doesn't actually solve my problem, which is that I don't want any composition api components in my project, and would have to spend the time to re-write any that exist over to options api. I want to start with a clean slate, and then build on top of it, adjusting things as I go. If anything, what your describing should just be a third option.

Project name: ... vue-project
Component Examples: ... Options API/ Composition API / Both
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

I can certainly see value in having both available to reference for those new to Vue, to save them a trip to the docs when just playing around. But to be crystal clear, unless I can use vue-create to make a new project written entirely in the options API, I can't use or recommend it to anyone, it is simply too much effort to have to "fix" it on every use to be considered a good boilerplate.

@sodatea

I believe this above approach addresses all previous concerns. It would not force an arbitrary choice for users ("both" could be the default). It would not confuse any newcomers as it is clear that both APIs can be used together, and in fact improves their early Vue experience by presenting both together as an option. It saves everyone time (people that only want composition API or only want Options API get that out of the box). Though there would be additional files to maintain, the complexity would remain very low (they are just duplicates of the existing defaults).

If the above approach is acceptable (Component Examples: ... Options API / Composition API / Both), I can begin a PR to add this feature. My approach would be to create the following folders:

• options-api-default/src - copy of default/src with components re-written using the Options API
• options-api-router/src - copy of router/src with components re-written using the Options API
• both-apis-default/src - copy of default/src with some components re-written using the Options API, while others aren't
• both-apis-router/src - copy of router/src with some components re-written using the Options API, while others aren't

Details can be addressed in review comments.

from create-vue.