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 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.
I'm Drew Town a web developer and systems engineer in Colorado. Always learning, traveling and exploring. Sharing updates, trials and tribulations in tech and life.
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.
I'm Drew Town a web developer and systems engineer in Colorado. Always learning, traveling and exploring. Sharing updates, trials and tribulations in tech and life.
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.
I'm Drew Town a web developer and systems engineer in Colorado. Always learning, traveling and exploring. Sharing updates, trials and tribulations in tech and life.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 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.
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.