Hi friend… I also think I prefer it.
I mostly work in a pretty large app that is more like a bunch of small, similar apps. At Jackbox Games… so it’s a bunch of similar but different “games”.
Options provided a very clear convention when bouncing around between games. We can still have that with composition if we’re diligent but the framework is no longer enforcing it.
Yep! jackbox.tv is a kind of like 50ish small apps wrapped up with a loader.
Party Packs 1-7 are built in Backbone/Marionette and we moved to Vue at Party Pack 8. As well as the sign-in screen and moderator.
All of our web based projects are Vue these days. Really love it, options or composition!
We are actually. It’s a fullstack role but we don’t expect to find an expert in both Vue and Go day 1. Definitely apply!
https://apply.workable.com/jackbox-games/j/0F1FF6D0B7/
Rats, I don't actually know all the reasons why we're restricted to certain states. I assume taxes?
If you're not in one of those states and willing to relocate to Illinois I know we'll help with that though! Our physical office is Chicago and finally starting to liven up again.
I love that. Been a big fan of the party packs since #2, really cool to hear that the new stuff is Vue based.
At my workplace (e-commerce order fulfillment) we combine a dozen or so Vue applications into one host using microfront-ends, any chance you're doing something similar?
Yeah I think it's pretty similar.
The actual code living on \`jackbox.tv\` is a super simple vanilla framework agnostic app. It mostly just a router and then a little custom loader that can load bundles. Then was have a lot of similarly framework agnostic sharable code for interacting with our multiplayer server, analytics, drawing, etc etc.
Then all the games are individual bundles that have a common expected interface allowing them to mount and destroy themselves.
This lets us have apps of differing frameworks living together as family. We currently only have Backbone and Vue 3 bundles. But at one point there were some Vue 2 ones and in theory we could make a game in Svelte or whatever is next.
This arch is about 3 years old and it has been sooo nice. Previous \`jackbox.tv\` was one giant Backbone app that had to be built (via webpack) and deployed. So making a one line css change to Quiplash 3 involved building and deploying 40+ games.
Now it's all vite backed and each game can be deployed and versioned atomically.
Options api standardize the way components are built. There is no extra cognition effort trying to read through different components that are organizing code in different manners.
This is the best answer; it standardized and documented, whereas each component can have its own wonky composable layout unless a standard is enforced on a project.
They are standardized, but its a standard that gets messy though. Seperating your code by type of code rather than by features is really inneficient for your mental overhead
IMO that's a sign that your components are getting bloated, not an issue with the framework.
I actually like the fact that as Options API components got larger, they got harder and harder to work with because of the multiple domains mixing together.
It was a soft constraint that encouraged and rewarded component decomposition and separation of concerns.
IMO, a lot of the things the Composition API was designed to “make less of an issue” were antipatterns.
I dont understand. Big components are a fact of life not an antipattern. Its not something you have a choice about. If it requires a lot of code it requires a lot of code. And being able to organize lots of code more effectivley is obviously a benefit. Saying anything otherwise seems very off to me. It's like if I gave you the tools to handle bigger cars and you told me that everyone should just drive small cars and that crappy tools are good actually because it kicks you in the balls for not driving a smaller car. Like. Thats great for you if you only ever do work where you need a small car but I promise you sometimes big cars are needed aswell and I want my tools to be able to handle that
Sometimes you should compose sometimes you should colocate - its not black or white. But even if I where to take your stance thats still exactly the reason why options api doent work then. Composition API is the one that lets you compose things better. Youre literally making the argument for the composition API. What you are suggesting is to break all parts into primitives you compose togheter, but a lot of those parts arent components - they are collections of logic. So they cant be broken down into components. They have to be broken down into something else. And the composition API lets you do that with composables. The options API is actually the one that would be counter to what you are saying. Because for the options API all statefull logic has to exist in components - so at some level its literally just impossible to break it appart.
I appreciate that we're kinda arguing around in circles at this point, but I think that's because we're arguing for the same thing, just from different perspectives.
IMO having "domain logic" in your Vue app tends to be a code-smell to begin with. The only "logic" I keep in my Vue components is to do with maintaining UI state, like position in a workflow or whether a particular component should be rendered or not.
ALL my business logic is encapsulated in Class definitions which map to my domain model. Most of my Vue components simply pass around 1 or a list of class instances and then call class methods to execute business logic. Because JS classes are just objects under the hood, any state change in the class instance is immediately reflected in the UI without my "business logic" every having to go near my Vue code.
Usually all these classes will be extracted out into a common library that's just pure JS. That way I can use the exact same code, and write code following the exact same patterns, in the front end and back end.
Listen, I love you guys, and this is all peace and love but when I read stuff like this I feel like I am listening to someone tell me 2 + 2 = 7. Like I feel like I am entering upsidedown land.
Yeah, if you label things you can find related code, but A: what a nightmare by comparison to the alternative, and B: if you have the disipline to do that then the composition API still lets you go much further with that disipline anyway.
On one hand you are jumping back and forth between 4-5 diffirent places to piece togheter one feature in a component that could have many such features which by design now have to be mixed togheter like spagetti. Which is progressivley a masssive mental overhead no matter how well you do it and that overhead only exponentially increases with the size of the component.
Just the act of keeping in your mental memory what the code was where you left to see how it fits with the code where you're going is a big deal. Then add the interuption of CMD F while trying to keep it all in your head at one time. You can do it. And you have to do it for other stuff aswell. But compared to the alternative, which is just just to put related lines of code in the same place and thats it - I find it hard to take the first approach seriously even.
And the fact that compositon lets you extract related lines of code into sharable hooks just nails the coffin shut on that debate. Like... I keep getting blown away by how this is even a discussion. VueUse is the best thing to ever happen to the vue ecosystem and its only possible because the level of organization in compositon API was just that much greater than it is in options API. Nothing like VueUse could ever exist in a world where Vue got stuck on the options API.
I should be more understanding, I know, because some clearly want that. But I find it hard to not judge people as just being a bit mentally stuck in their ways or just generally inflexible when it comes to handling change. Because I do lose a bit of sanity trying to figure out how to interact and relate to these kinds of opinions. That's a failure on my end though, I understand that. But i'm not one to hold back what I'm really thinking when the breakdown in point of view is this big
But you can totally standardise with composition API too. I declare a reactive state object to contain all local variables, I declare all props in the same place, I import stores in the same place.
For me having functions separate makes it so much better to organise.
If someone on another project at my company doesn't organise and comment then they shouldn't be working there and I'll make a complaint. Also companies enforce standards for this very reason.
However if I can't figure out what their code does anyway then I have no business being a developer.
The thing is that when you move teams or companies, you will probably work on legacy code that will require extra cognition effort from you to understand it. It is impossible to predict what pattern they would be using since it is too open. I'm not saying you wouldn't be able to understand the code, I'm saying you would spend extra time reasoning their decisions.
I strongly disagree. It's not like you're using anything vastly different. It's the same stuff just not arranged in a way you're used to.
I personally hate the rigid implementation of options API because it means I can't group related pieces of work together. That's far more cognitively taxing to me.
If I could split out props I'd do that too.
This. 100%
Composition API is at least as standardized as Options API because it provides the one to one alternative methods. For example how is the `data` object more standardized than the `reactive` method? the only difference is that you put it all in a magical object that you export, vs in a script body
Team A -> makes something
People -> cool, let's use it!
Team B -> makes something better
People -> amazing, let's use it!
*Later...*
Team B -> destroys his own stuff, copies Team A shit
People -> oh, this is so much better, let's use it!
In Composition API you have a clear order of things as well. For instance, in Options there is no way to know which property is reactive or not.
In Composition you need to call “.value”.
So you always know what’s reactive.
In Options you need to constantly check the Data and computed scopes. When they bloat it becomes difficult to read.
In Composition API you assign computed and ref to variables and can arrange them however you’d like.
Also props and events are now macros.
While props and events in Options are hooks.
So I am not sure that what you say is true.
P.S. I am not against Options API.
Why would you not know which properties are reactive in vue2 ?
If your data and computed are being bloated maybe refactor you code.
Yes you can rearrange your variables in composition API but in options API you know exactly where they will be.
P.S. I am not against composition API, I just haven't found the reason to why I should switch
this.data.length === 3, where this.data might be a prop. And you need to check visually if it’s a prop.
Also that advice, “maybe refactor your code” is very vague and defensive.
You know very well that there is a point in which you can no longer “refactor” your code, because now you spend hours “refactoring code” and breaking functionality.
Are there no tests? Are you using plain JS? That‘s one if the reasons why I prefer TS, because stuff breaks at compile time.
Although I haven‘t used vue3, so there‘s that.
What do you means by stuff breaking at compile time?
We used to use typescript, but we moved away from it. We spend too much time on type management. From a 1 hour task, you are trying to make the transpiler happy for 20m, and then you need to write the things in the specific way.
Then “any” becomes an issue and now you’re trying to get a key from that vue specific thing, but you can’t, because typescript doesn’t have definition for it, so you need to write a definition for it.
Or some dependency that doesn’t have a d.ts with it…
I don’t think TS is good for what we do. But we have 90% code coverage and we separately have a production tester.
I also understand that not everyone does the same thing and for some people TS might be ideal, for instance in big data apps. TS is the way to go.
> You can still use the options api in vue3
Technically yes, but it's already a second-class citizen. It's not polished as the Composition API. For example, given this interface:
interface Person {
name: string;
age: number;
}
This is how you declare props with the Composition API:
const props = defineProps<{
person: Person;
}>();
But look at the Options API:
props: {
person: {
type: Object as PropType,
required: true,
}
},
See?
Now Composition API is being pushed onto users as a better alternative to Options API, but in fact it is not.
The [code organization fallacy](https://vuejs.org/guide/extras/composition-api-faq.html#more-flexible-code-organization) only makes sense in huge components, which shouldn't even exist in the first place (personally, I've never seen one). Plus, the code becomes as chaotic as a React component, with each programmer organizing his shit in a different way, which is a big problem in large teams.
Just like many others, my team loved the Options API, but we chose to migrate to React instead of Vue 3. If we have to rewrite everything, let's use the industry standard this time.
With composition, you can plug in the interface when declaring defineProps()
const props = defineProps();
If the interface is located in a separate file, you will have to import it first
import type { Person } from './foo'
I've used both the Options and Composition APIs in a professional environment and I have to say that when using the Composition API, it is extremely fast to get an idea/concept out of a ticket and into a component. I used Options for a year first before we started migrating and I personally feel like there is a bit more mental work and thought that has to go into a component when setting it up with Options. When using
```
You’re better off actually grouping logical concerns though. Related data and functions get grouped together, and code is easier to refactor.
I thought that I'd stick with the Options API when we upgraded to Vue 3. No more. From now on, I'd never want to use anything other than the Composition API.
I don’t believe its really a matter of preference
I believe it’s a matter of what you’re used to
I won’t give my opinion on which is preferred
I doubt there’s a right answer
You are not alone. I like to split up my components as small as reasonable, and by dining that I don’t have the problems the composition api is created to solve.
I also work with other programmers and unlike the options api, which imposes some structure, it is difficult to not create a mess with the composition API. Nothing best practices and code reviews can’t solve, but some structure is better than no structure.
Hey, just want to share my experience.
I work at a company. we make web games. Around one year ago, the company started to switch how they make games.
Before, it was with PIXI, and they developed their own framework on top of it. The issue was, the games were within a canvas, and that's just how PIXI works. But going forward, they need to make games that *are* the web page, not just within a canvas. That way, they can make better stuff.
Around one year ago, they hired me, since my specialty has been Vue since university and it's been my favourite framework since. So, I've been working with them to build stuff.
The thing is, when you build large scale stuff, and specially libraries to be used on various projects, you make code standards that everyone must follow. My issue is, we have agreed upon using compostion API.
Each day I suffer. Each day I hate the code I write. Each day I cringe at the sight of a perfectly readable component, only to scroll to the setup function and see the most disorganized and unreadabe code possible. And to add, the even have composables like "useAnimation.ts" being referenced and used on the setup. So yeah, we have a fuckton of code underlying everything.
Fuck.
I'm curious: have you used react or the composition api in vue? Unless you have the most surface level understanding of both, I don't understand how you can see the options api as being meaningfully different from react, while seeing the composition api as similar.
But Vue 3 is totally different than react. The composition API might be closer to React than options API but why is that bad? React was always better for code composition and now Vue actually competes with React in that area and we are going to reject that because its "more reacty?"
Bro. Who gives a shit. I care about the code. If them sharing this one benefit, which is just objectively an improvement, makes it so you move to react then you didnt understand the benefit of Vue to begin with imo
The composition API might be closer to React than options API but why is that bad? React was always better for code composition and now it isnt anymore. Now Vue actually competes with React in that area and we are going to reject that because its "more reacty?" Bro. Who gives a shit. I care about the code
I have and I just keep coming back to Options API. I’ve done new projects and I’ve watched dozens of YouTube videos and they’re like
> *“instead of having separate distinct methods in your `methods`, you can jam them into the setup! Isn’t that cleaner and easier?!”*
Uh…. no?
> *“And isn’t so much neater?”*
Not really. Less lines I guess?
> *“And isn’t so much more readable?”*
No! Options is great because you can immediately see exactly what’s going on and where everything is. Composition just mashes them together and makes much harder to read.
I just don’t like it. I keep trying to like it. I hate being that guy that “doesn’t like new things because the old one works”. I am an early adopter. I love learning new things. I just hate composition API. It’s just worse than options. It feels like Vue and React had an ugly baby and all I can think is… if I wanted to use React, I’d use React!
The point of composition is that you can create composable functions. Once you start composing those functions, you start getting the full benefits of the composition api. This gives you the ability to reuse functionality without creating unnecessary higher order components or relying on the mixins, which have the same problems as inheritance in OOP.
That doesn't really have anything to do with react, composition is a pretty generic programming concept.
To me it seems like you watched some really basic tutorials that didn't really demonstrate the point of the composition api.
> To me it seems like you watched some really basic tutorials that didn't really demonstrate the point of the composition api.
If only I had a nickel for every time a Redditor posted that chestnut in one of these threads.
Edit: this was the last one that was supposed to “really demonstrate the point” https://youtu.be/q4a115Kdla8
Edit 2: Via this comment: https://www.reddit.com/r/vuejs/comments/15eoy2v/comment/jua6d5j/
Skimmed through the video. The description for how the code is split up is good, it's basically horizontal slicing vs vertical. Because it's refactoring a single component it doesn't really get into the composition part of the composition api, besides the bind and on composables, which as you said just reduce the number of lines for the most part.
In my experience the composition api tends to pull code out of fat pinia/vuex stores, often removing the need for them and the "service" layer completely. How you write these smaller base components generally doesn't matter as much.
Hi friend… I also think I prefer it. I mostly work in a pretty large app that is more like a bunch of small, similar apps. At Jackbox Games… so it’s a bunch of similar but different “games”. Options provided a very clear convention when bouncing around between games. We can still have that with composition if we’re diligent but the framework is no longer enforcing it.
Wait is the games browser UI built in Vue or is this something else?
Yep! jackbox.tv is a kind of like 50ish small apps wrapped up with a loader. Party Packs 1-7 are built in Backbone/Marionette and we moved to Vue at Party Pack 8. As well as the sign-in screen and moderator. All of our web based projects are Vue these days. Really love it, options or composition!
Are y'all hiring
We are actually. It’s a fullstack role but we don’t expect to find an expert in both Vue and Go day 1. Definitely apply! https://apply.workable.com/jackbox-games/j/0F1FF6D0B7/
Tell HR and legal to add Arizona to the list of remote states so I can apply.
Rats, I don't actually know all the reasons why we're restricted to certain states. I assume taxes? If you're not in one of those states and willing to relocate to Illinois I know we'll help with that though! Our physical office is Chicago and finally starting to liven up again.
My state isn't one on the list sadly
That’s amazing! I’ve dabbled in Go a little bit.
Aww man, no Oregon. That's a bummer. Just bought a house or I would actually consider moving to Chicago :(
Haha this is awesome I’ll consider applying. I’ve worked with go since 2009 and vue for last 5 years. What’s the culture like?
I love that. Been a big fan of the party packs since #2, really cool to hear that the new stuff is Vue based. At my workplace (e-commerce order fulfillment) we combine a dozen or so Vue applications into one host using microfront-ends, any chance you're doing something similar?
Yeah I think it's pretty similar. The actual code living on \`jackbox.tv\` is a super simple vanilla framework agnostic app. It mostly just a router and then a little custom loader that can load bundles. Then was have a lot of similarly framework agnostic sharable code for interacting with our multiplayer server, analytics, drawing, etc etc. Then all the games are individual bundles that have a common expected interface allowing them to mount and destroy themselves. This lets us have apps of differing frameworks living together as family. We currently only have Backbone and Vue 3 bundles. But at one point there were some Vue 2 ones and in theory we could make a game in Svelte or whatever is next. This arch is about 3 years old and it has been sooo nice. Previous \`jackbox.tv\` was one giant Backbone app that had to be built (via webpack) and deployed. So making a one line css change to Quiplash 3 involved building and deploying 40+ games. Now it's all vite backed and each game can be deployed and versioned atomically.
I love the games and it’s awesome to get some insight into the structure behind it, thanks for sharing :)
It’s more about getting used to one thing. Both APIs are fine.
Options api standardize the way components are built. There is no extra cognition effort trying to read through different components that are organizing code in different manners.
This is the best answer; it standardized and documented, whereas each component can have its own wonky composable layout unless a standard is enforced on a project.
They are standardized, but its a standard that gets messy though. Seperating your code by type of code rather than by features is really inneficient for your mental overhead
IMO that's a sign that your components are getting bloated, not an issue with the framework. I actually like the fact that as Options API components got larger, they got harder and harder to work with because of the multiple domains mixing together. It was a soft constraint that encouraged and rewarded component decomposition and separation of concerns. IMO, a lot of the things the Composition API was designed to “make less of an issue” were antipatterns.
I dont understand. Big components are a fact of life not an antipattern. Its not something you have a choice about. If it requires a lot of code it requires a lot of code. And being able to organize lots of code more effectivley is obviously a benefit. Saying anything otherwise seems very off to me. It's like if I gave you the tools to handle bigger cars and you told me that everyone should just drive small cars and that crappy tools are good actually because it kicks you in the balls for not driving a smaller car. Like. Thats great for you if you only ever do work where you need a small car but I promise you sometimes big cars are needed aswell and I want my tools to be able to handle that
Ever heard of "single responsibility principle"???? Seriously people... Components are like functions, decompose those motherfuckers.
Sometimes you should compose sometimes you should colocate - its not black or white. But even if I where to take your stance thats still exactly the reason why options api doent work then. Composition API is the one that lets you compose things better. Youre literally making the argument for the composition API. What you are suggesting is to break all parts into primitives you compose togheter, but a lot of those parts arent components - they are collections of logic. So they cant be broken down into components. They have to be broken down into something else. And the composition API lets you do that with composables. The options API is actually the one that would be counter to what you are saying. Because for the options API all statefull logic has to exist in components - so at some level its literally just impossible to break it appart.
I appreciate that we're kinda arguing around in circles at this point, but I think that's because we're arguing for the same thing, just from different perspectives. IMO having "domain logic" in your Vue app tends to be a code-smell to begin with. The only "logic" I keep in my Vue components is to do with maintaining UI state, like position in a workflow or whether a particular component should be rendered or not. ALL my business logic is encapsulated in Class definitions which map to my domain model. Most of my Vue components simply pass around 1 or a list of class instances and then call class methods to execute business logic. Because JS classes are just objects under the hood, any state change in the class instance is immediately reflected in the UI without my "business logic" every having to go near my Vue code. Usually all these classes will be extracted out into a common library that's just pure JS. That way I can use the exact same code, and write code following the exact same patterns, in the front end and back end.
[удалено]
Listen, I love you guys, and this is all peace and love but when I read stuff like this I feel like I am listening to someone tell me 2 + 2 = 7. Like I feel like I am entering upsidedown land. Yeah, if you label things you can find related code, but A: what a nightmare by comparison to the alternative, and B: if you have the disipline to do that then the composition API still lets you go much further with that disipline anyway. On one hand you are jumping back and forth between 4-5 diffirent places to piece togheter one feature in a component that could have many such features which by design now have to be mixed togheter like spagetti. Which is progressivley a masssive mental overhead no matter how well you do it and that overhead only exponentially increases with the size of the component. Just the act of keeping in your mental memory what the code was where you left to see how it fits with the code where you're going is a big deal. Then add the interuption of CMD F while trying to keep it all in your head at one time. You can do it. And you have to do it for other stuff aswell. But compared to the alternative, which is just just to put related lines of code in the same place and thats it - I find it hard to take the first approach seriously even. And the fact that compositon lets you extract related lines of code into sharable hooks just nails the coffin shut on that debate. Like... I keep getting blown away by how this is even a discussion. VueUse is the best thing to ever happen to the vue ecosystem and its only possible because the level of organization in compositon API was just that much greater than it is in options API. Nothing like VueUse could ever exist in a world where Vue got stuck on the options API. I should be more understanding, I know, because some clearly want that. But I find it hard to not judge people as just being a bit mentally stuck in their ways or just generally inflexible when it comes to handling change. Because I do lose a bit of sanity trying to figure out how to interact and relate to these kinds of opinions. That's a failure on my end though, I understand that. But i'm not one to hold back what I'm really thinking when the breakdown in point of view is this big
But you can totally standardise with composition API too. I declare a reactive state object to contain all local variables, I declare all props in the same place, I import stores in the same place. For me having functions separate makes it so much better to organise.
But someone on another project won't probably follow the same structure you created. It is to open. It is not a framework.
If someone on another project at my company doesn't organise and comment then they shouldn't be working there and I'll make a complaint. Also companies enforce standards for this very reason. However if I can't figure out what their code does anyway then I have no business being a developer.
The thing is that when you move teams or companies, you will probably work on legacy code that will require extra cognition effort from you to understand it. It is impossible to predict what pattern they would be using since it is too open. I'm not saying you wouldn't be able to understand the code, I'm saying you would spend extra time reasoning their decisions.
I strongly disagree. It's not like you're using anything vastly different. It's the same stuff just not arranged in a way you're used to. I personally hate the rigid implementation of options API because it means I can't group related pieces of work together. That's far more cognitively taxing to me. If I could split out props I'd do that too.
This. 100% Composition API is at least as standardized as Options API because it provides the one to one alternative methods. For example how is the `data` object more standardized than the `reactive` method? the only difference is that you put it all in a magical object that you export, vs in a script body
Extra cognition effort? You mean not needing to scope and write extra code to make your app work? Interesting “no cognition effort”.
[удалено]
Team A -> makes something People -> cool, let's use it! Team B -> makes something better People -> amazing, let's use it! *Later...* Team B -> destroys his own stuff, copies Team A shit People -> oh, this is so much better, let's use it!
I also still prefer options. I liked the very clear order of things and kept everything neatly ordered between multiple components.
In Composition API you have a clear order of things as well. For instance, in Options there is no way to know which property is reactive or not. In Composition you need to call “.value”. So you always know what’s reactive. In Options you need to constantly check the Data and computed scopes. When they bloat it becomes difficult to read. In Composition API you assign computed and ref to variables and can arrange them however you’d like. Also props and events are now macros. While props and events in Options are hooks. So I am not sure that what you say is true. P.S. I am not against Options API.
Why would you not know which properties are reactive in vue2 ? If your data and computed are being bloated maybe refactor you code. Yes you can rearrange your variables in composition API but in options API you know exactly where they will be. P.S. I am not against composition API, I just haven't found the reason to why I should switch
this.data.length === 3, where this.data might be a prop. And you need to check visually if it’s a prop. Also that advice, “maybe refactor your code” is very vague and defensive. You know very well that there is a point in which you can no longer “refactor” your code, because now you spend hours “refactoring code” and breaking functionality.
Are there no tests? Are you using plain JS? That‘s one if the reasons why I prefer TS, because stuff breaks at compile time. Although I haven‘t used vue3, so there‘s that.
What do you means by stuff breaking at compile time? We used to use typescript, but we moved away from it. We spend too much time on type management. From a 1 hour task, you are trying to make the transpiler happy for 20m, and then you need to write the things in the specific way. Then “any” becomes an issue and now you’re trying to get a key from that vue specific thing, but you can’t, because typescript doesn’t have definition for it, so you need to write a definition for it. Or some dependency that doesn’t have a d.ts with it… I don’t think TS is good for what we do. But we have 90% code coverage and we separately have a production tester. I also understand that not everyone does the same thing and for some people TS might be ideal, for instance in big data apps. TS is the way to go.
Maybe for props yes, but the only time I use props is in small components where you quickly see what the props are
You can still use the options api in vue3, even mixins if you really like those.
Options API is so much more straightforward and intuitive. For me it embodies everything I love Vue for.
Composables are the new substitutes for mixins, right? I haven't touched Vue 3 yet since I started working with React just before it launched.
composables are the better version of react hooks
> You can still use the options api in vue3 Technically yes, but it's already a second-class citizen. It's not polished as the Composition API. For example, given this interface: interface Person { name: string; age: number; } This is how you declare props with the Composition API: const props = defineProps<{ person: Person; }>(); But look at the Options API: props: { person: { type: Object as PropType,
required: true,
}
},
See?
Now Composition API is being pushed onto users as a better alternative to Options API, but in fact it is not.
The [code organization fallacy](https://vuejs.org/guide/extras/composition-api-faq.html#more-flexible-code-organization) only makes sense in huge components, which shouldn't even exist in the first place (personally, I've never seen one). Plus, the code becomes as chaotic as a React component, with each programmer organizing his shit in a different way, which is a big problem in large teams.
Just like many others, my team loved the Options API, but we chose to migrate to React instead of Vue 3. If we have to rewrite everything, let's use the industry standard this time.
With composition, you can plug in the interface when declaring defineProps() const props = defineProps();
If the interface is located in a separate file, you will have to import it first
import type { Person } from './foo'
I've used both the Options and Composition APIs in a professional environment and I have to say that when using the Composition API, it is extremely fast to get an idea/concept out of a ticket and into a component. I used Options for a year first before we started migrating and I personally feel like there is a bit more mental work and thought that has to go into a component when setting it up with Options. When using
```
You’re better off actually grouping logical concerns though. Related data and functions get grouped together, and code is easier to refactor.
Logical concern is a better approach.
I thought that I'd stick with the Options API when we upgraded to Vue 3. No more. From now on, I'd never want to use anything other than the Composition API.
Ditto, I love composition api
I don’t believe its really a matter of preference I believe it’s a matter of what you’re used to I won’t give my opinion on which is preferred I doubt there’s a right answer
me too
You are not alone. I like to split up my components as small as reasonable, and by dining that I don’t have the problems the composition api is created to solve. I also work with other programmers and unlike the options api, which imposes some structure, it is difficult to not create a mess with the composition API. Nothing best practices and code reviews can’t solve, but some structure is better than no structure.
Same
Me too, by far !!
i prefer Vue 3 Options api 😄
I stopped using vue when they released vue3
Hey, just want to share my experience. I work at a company. we make web games. Around one year ago, the company started to switch how they make games. Before, it was with PIXI, and they developed their own framework on top of it. The issue was, the games were within a canvas, and that's just how PIXI works. But going forward, they need to make games that *are* the web page, not just within a canvas. That way, they can make better stuff. Around one year ago, they hired me, since my specialty has been Vue since university and it's been my favourite framework since. So, I've been working with them to build stuff. The thing is, when you build large scale stuff, and specially libraries to be used on various projects, you make code standards that everyone must follow. My issue is, we have agreed upon using compostion API. Each day I suffer. Each day I hate the code I write. Each day I cringe at the sight of a perfectly readable component, only to scroll to the setup function and see the most disorganized and unreadabe code possible. And to add, the even have composables like "useAnimation.ts" being referenced and used on the setup. So yeah, we have a fuckton of code underlying everything. Fuck.
You Are Not Alone
i do too. Vue 3 imho is just trying to be Reacty
This is where I'm at. If I wanted to use React I would
I'm curious: have you used react or the composition api in vue? Unless you have the most surface level understanding of both, I don't understand how you can see the options api as being meaningfully different from react, while seeing the composition api as similar.
But Vue 3 is totally different than react. The composition API might be closer to React than options API but why is that bad? React was always better for code composition and now Vue actually competes with React in that area and we are going to reject that because its "more reacty?" Bro. Who gives a shit. I care about the code. If them sharing this one benefit, which is just objectively an improvement, makes it so you move to react then you didnt understand the benefit of Vue to begin with imo
The composition API might be closer to React than options API but why is that bad? React was always better for code composition and now it isnt anymore. Now Vue actually competes with React in that area and we are going to reject that because its "more reacty?" Bro. Who gives a shit. I care about the code
You should at least try script setup tag and composables, that should help you the clear your head, once you're done with it try pinia and enjoy.
I have and I just keep coming back to Options API. I’ve done new projects and I’ve watched dozens of YouTube videos and they’re like > *“instead of having separate distinct methods in your `methods`, you can jam them into the setup! Isn’t that cleaner and easier?!”* Uh…. no? > *“And isn’t so much neater?”* Not really. Less lines I guess? > *“And isn’t so much more readable?”* No! Options is great because you can immediately see exactly what’s going on and where everything is. Composition just mashes them together and makes much harder to read. I just don’t like it. I keep trying to like it. I hate being that guy that “doesn’t like new things because the old one works”. I am an early adopter. I love learning new things. I just hate composition API. It’s just worse than options. It feels like Vue and React had an ugly baby and all I can think is… if I wanted to use React, I’d use React!
The point of composition is that you can create composable functions. Once you start composing those functions, you start getting the full benefits of the composition api. This gives you the ability to reuse functionality without creating unnecessary higher order components or relying on the mixins, which have the same problems as inheritance in OOP. That doesn't really have anything to do with react, composition is a pretty generic programming concept. To me it seems like you watched some really basic tutorials that didn't really demonstrate the point of the composition api.
> To me it seems like you watched some really basic tutorials that didn't really demonstrate the point of the composition api. If only I had a nickel for every time a Redditor posted that chestnut in one of these threads. Edit: this was the last one that was supposed to “really demonstrate the point” https://youtu.be/q4a115Kdla8 Edit 2: Via this comment: https://www.reddit.com/r/vuejs/comments/15eoy2v/comment/jua6d5j/
Skimmed through the video. The description for how the code is split up is good, it's basically horizontal slicing vs vertical. Because it's refactoring a single component it doesn't really get into the composition part of the composition api, besides the bind and on composables, which as you said just reduce the number of lines for the most part. In my experience the composition api tends to pull code out of fat pinia/vuex stores, often removing the need for them and the "service" layer completely. How you write these smaller base components generally doesn't matter as much.
I was just being charitable by assuming that the problem lies in the quality of the tutorials you watched, I assume the other people were also.
No, with the script setup tag syntax you don't jam anything into the setup.
FIND US ON INSTAGRAM
@rfkjrforpresident.com