Love at first Vue
I was an early adopter of Vue.js in 2016, and my very first project with the framework was to port an existing Vue 1 a...
For further actions, you may consider blocking this person and/or reporting abuse
I don't see why the composition API is a problem here. I think it is the right solution to a completely different problem. You talk about code reuse but mean business logic. These are two different things. Code reuse obviously applies to business logic as well but that doesn't mean it doesn't apply to the view layer.
Also you also show snippets of discussions without enough context. The composition API is meant to fix very vue-specific problems and it does this well. Some people thought it will change the way to use Vue because they jumped to conclusions too quickly. The same angry people also cried out loud when they heard that Vue3 will be written in TypeScript because again they jumped to the wrong conclusions.
I agree. I've worked on some medium sized enterprise apps and code reuse in the view layer was definitely a problem. A problem that composition API could have helped us solve. We tried renderless components, we tried just importing functions, we tried overly bloated base components. All of these felt clunky because we couldn't share functionality between components without this odd non-standard layer.
The composition API is definitely solving a problem. It may not be a problem everyone has but it is a problem. I'll rarely, if ever, use it on my little blog website but I would have used it all the time at my previous job.
I've also consulted on large enterprise apps where the team has quickly hit problems with a bloated structure of components, and so far the solution was never mixins or renderless components but rather plain old JavaScript in the form of service classes, auxiliary helper functions or simply refactoring and breaking down the components.
Oh I don't disagree that helper functions and service classes can solve many code re-use problems especially around business logic type problems and API access. And that's what we did.
I do think the the composition API will help with view layer re-usability problems. Things like a drag-and-drop library, event handling, special formatting logic (numbers, truncation, etc. etc.) and animations. Those were our big pain points of trying to figure out good ways to re-use Vue code.
Yes, I know for some of those you could pull in a special helper function and run it through a method. But, it would have been nice to be able to use computed and watch methods in some of them rather than have to remember to use that method on all changes
I get what you mean because I've had to make these decisions when refactoring too. In 90% of the cases where I've needed to reuse code at the level of computed properties or watchers, it has turned out in the end that my component structure wasn't optimal and could be refactored or further broken down into sub components.
In the other 10% it was always the case that I am trying to keep the code DRY at the micro level where some duplication simply won't hurt.
The problem we were having is with tons of little components scattered around we were setting pretty bad perf problems when loading large data sets. The comp API seems promising in that it shouldn't have the same perf cost as rendering a full component.
I don't think it'll be perfect for all situations but I think it'll be a nice tool to have IF you need it. I don't think most end users will need it often.
I'm all for having more tools at our disposal.
My only concern was that if suddenly all the documentation and tutorials for new users are with the Composition API this might firstly hurt Vue.js adoption and secondly lead to the eventual deprecation of the Options API.
I am including encapsulation of business logic when I talk about the topic of code reuse simply because both things were used as justifications for the Composition API's existence.
Also, the official plan was to change the way to use Vue by deprecating the Options API, so no jumping to conclusions there. That plan was thankfully laid to reset after the much deserved developer outcry.
You are right that there is not enough context for the screenshots of conversations but sadly I couldn't find the link to Akryum's Gist where one of the discussions took place.
You've failed to give us your idea or suggestion as to what the better solution to better code reuse could have been and why it would be better. So, this article ends up just sounding like a rant to me.
You do mention refactoring because, if one needs the composition API, they are more then likely doing something wrong and could just refactor. Really? Are you sure that is true? I don't. My best guess is, you've not understood how the Composition API can help you and thus, haven't embraced the fact it could help you. That's ok. But, you shouldn't write about your lack of understanding like this, as if it's Vue's problem, in a rant. There are many other devs who are embracing it. They can't all be wrong. Right?
You also fail to mention the other main reason for this API direction of Vue - It's for a much better TypeScript support. This is very important for larger developer teams (too) and developer ease of use. (You do understand that I hope). That shouldn't be forgotten or rather should be weighed against the cons of the API, which you also fail to mention in any detail. You never say the new API has inherent problems, except your opinion of it possibly disrupting some delicate balance Vue makes between React and Angular. I disagree wholeheartedly against this perspective. That might have been the case while Vue was growing, now Vue needs to grow in other directions. And, the new Composition API will pull more (smart) React and Angular devs and companies using these technologies to Vue, strengthening its place in the market and allowing that growth.
I will agree that it is very easy to muddle up code reuse concepts with all the new possibilities we are seeing with single file components. In Jake Schatz's presentation you elude to, Jake is trying to give the message of not allowing business "knowledge" to leak into the UI. He is clearly demonstrating we should use abstractions to simplify code and enable better code reuse. He notes two patterns, the "builder" and the "command" design patterns. And, if we are brutally honest, the Composition API is 100% built to support both patterns much better than the current and often loved Options API (I love it too, btw). Imagine a "useCommand" or "useBuilder" and "useDirector" functions (objects).
So, unless you can come up with a better solution, you should stop ranting, because that is all it is. A rant. It has no value other than to get your opinion out in the open. And, you should know, opinion without reasonable and substantiating fact is a lousy opinion. Sorry, but if you want to back up your opinion, come up with what you feel could have been a better direction and why. Then your rant isn't just a rant, but a smart counter argument and I personally would thank you for it.
I am sorry if my personal rant has offended you. You are right that I should have expanded on some points like what a better alternative would look like.
Personally I don't think that Vue.js needed better methods for code reuse because, like I said in my article, if you end up needing composition functions or mixins, your problems could probably be solved by other forms of refactoring – e.g. breaking components down and using vanilla service classes.
Otherwise, if you or the core dev team insist on changing the way Vue works, the now abandoned Class API would have been a much better alternative, and in fact it would have been much more idiomatic OOP Typescript, if you're all about the improved TS support.
If you fail to see the merit of my "balance between Angular and React argument", then you are severely misunderstanding the position Vue occupies in the general JavaScript ecosystem. As a consultant I've helped multiple middle sized to large companies introduce Vue.js to their dev teams, and "better code reuse" or "better typescript support" were literally never mentioned as reasons. The single most often mentioned reason was that Vue.js has a much flatter learning curve and (compared to Angular and React) much less boilerplate, i.e. "the fine balance" I was referring to in my article.
If a team would find themselves in the position of needing much more strictly organized code structure or much better native TypeScript support, they would simply reach for Angular. If on the other hand, they need much better and "pure" functional approach to their code base, they would simply reach for React. My point is, those use cases are already solved better in other frameworks, and Vue should stick to what makes it desirable in the first place. Vue is not a silver bullet that is valid in all the use cases.
I think you summarized very well what i always thought. Thanks.
If you think composition API solves anything for you you probably need to switch to React, Vue philosophy of coding is specifically about options API and proper app architecture. I personally work with Vue since 2015 and never ever had issues with code reusing. Composition API is the worst that happened to Vue and may actually lead to it slow death as there is no more point of using Vue when it's basically the same as React.
When I saw the composition API, I thought it could be a neat tool in the toolbox.
If we're talking about business logic in the view layer though, I have to agree—especially when the view layer is handled completely in the browser as in SPAs.
Before I heard about Vue a few years ago, I was learning Meteor. It was a fun tool to learn and I loved the idea of using a framework that was an SPA out of the box and used JS on both client and server. But there was a practice (even encouraged in the docs) of running some Meteor methods that would normally need to be run server-side to update MongoDB also on the client (the client side used MiniMongo as its data store).
So it was trying to do DB updates in both to give the appearance that the changes happened more quickly—and then the changes would be rolled back if the server side contradicted the change made client-side.
I really don't understand why exposing all of this to the browser is/was thought to be ok, so I definitely agree with you about keeping business logic separate.
Vue 3 and the Composition API is not going towards React, it is going towards the platform (ES-Proxies for Reactivity, reusable within ES-Modules). And Vue has never been "between React and Angular" (perhaps between AngularJS), because Angular has nothing to do with the platform. It's the GWT successor and tries to completely abstract the platform - it would not matter if it uses Java, Dart (there is IMHO an Angular-Dart project inside Google) or TS. Since TS is something close to Java there is no need for a Java-Compiler. But with all its proprietary stuff like Class-based Components, Annotations, Dependency-Injection, Modularization, Observables etc. it is far from Vue per definition.
There was never an "initial plan to deprecate the old component syntax" (a.k.a. Options API) . Your claim this plan was abandoned "thanks to the huge developer outcry" is, technically, a big fat lie.
When you lie, everything else you ever said gets devalued.
From the outside, you seem frustrated. Perhaps you should feel grateful. Every time you complete a project using Vue, regardless of which syntax you prefer, remember your awesomeness was made possible by the core team.
It was certainly a plan to abandon options API in the beginning. Even now all new documentation is written in composition API, which indicates that it's preferable. Keeping two very different APIs is something that leads to lots of problems in documentation, for anyone learning Vue and just for new projects when people start using composition API without even knowing that there is options API and it's much cleaner and simpler. Even if this is not a deprecation of options API now, eventually this approach will lead to it later.
Vue3 s*cks. Bring back the beauty of the Vue2. I wonder who in a sane state makes an old version of syntax obsolete. Can you imagine getting a new EcmaScript version of javascript that makes all old code obsolete. Insane, and that's exactly what those fine gentlemen did with Vue V3.
below would equal true👇
vue3 - sfc + (render:() =>jsx) === react with hook.
BTW, vue3@beta is released and i had a try.In my own option I still prefer jsx rather sfc
It says "clean code" not oop code