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