Vue 3 Composition API – The Wrong Solution To The Right Problem

Martin Sotirov — Tue, 05 May 2020 10:25:25 +0000

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 app to the brand new Vue 2. As a React user I was skeptical at first. What I was seeing was a weird mixture of features “stolen” from all the major frontend frameworks.

It took almost no time for me to permanently fall in love though.

This “weird mixture” seemed to represent the perfect balance between React’s flexibility, Angular’s structured modules and jQuery’s flat learning curve.

And from then on, I was an early evangelist for Vue. I did presentations on Vue at all the major JavaScript meetups in my area. I went to the Vue.js Amsterdam conference every year.

I used Vue in all the projects where it made sense and in many where it was probably the wrong tool. I was even doing hybrid iOS apps with Cordova long before there were any solutions for Vue on mobile.

RFC shit storm

Then in June 2019 came the RFC shit storm when the Composition API was ~~announced~~ imposed.

During the heated discussions on GitHub, Hacker News and Reddit I had a some rather unpleasant interactions with core team members where I and everyone else who was disagreeing were told that we need React style hooks because all the business logic must be in components and they know best because it's their framework.

Martin Sotirov

@unclemartycodes

Sad to see the transition of my favorite #FrontEnd framework #VueJS to #React style hooks mishandled that badly. That's not how communication in an #opensource project should be.

07:21 AM - 25 Jun 2019

0 3

In the end, thanks to the huge developer outcry the initial plan to deprecate the old component syntax was abandoned, so v3 will still support the old Vue syntax we love. Yay!

The age-old problem of code reuse

The Composition API came about as a solution to the age-old problem of code reuse and encapsulation of business logic. Multiple programming languages have been born as a solution to this problem and in fact the whole discipline of Object Oriented Programming can be traced back to the dream of code reuse.

That problem has already been solved, and just because suddenly it's OK to have CSS in our JavaScript files, it doesn't mean we have to completely throw out 30 years of programming knowledge and completely reinvent everything.

In fact, if you read old versions of the Vue.js docs, you will see that it is advertised as the ViewModel in the MVVM design pattern (or MVP as Martin Fowler initially called it).

Technically, Vue.js is focused on the ViewModel layer of the MVVM pattern. It connects the View and the Model via two way data bindings.

Reuse of the ViewModel was never a goal for MVVM frameworks though! Neither is the encapsulation of "renderless" business logic not tied to a specific view. The ViewModel's sole job is to manage the state of a specific part of the app (a single component).

Thankfully, there are still sane voices in the JavaScript community which sadly aren't heard loud enough.

Martin Sotirov

@unclemartycodes

Amen! Someone had to say this today with everyone in #VueJS and #JavaScript throwing #DesignPatterns and old coding best practices out the window. Serverless this, renderless that, #GraphQL queries in the templates 😢 @jakecodes #vuejsamsterdam

16:50 PM - 14 Feb 2019

3 7

The wrong solution to the right problem

Code reuse and encapsulation of business logic absolutely are valid problems but bending a technology focused on the view layer of an application to do additional things is not the right solution.

The Composition API supposedly solves the problems with:

Mixins
Renderless Components
Higher Order Components

If you absolutely must use some kind of component inheritance and breaking your components down or extracting common functionality in service classes is not an option, that means you are either structuring your app's architecture the wrong way or Vue.js simply isn't the right tool for the project.

Vue.js is not a silver bullet that's applicable in 100% of the use cases, and that's ok.

It is simply unfortunate that when the Vue.js Core Team tried to solve the age-old problem of code reuse and business logic encapsulation, they decided to find inspiration in React rather than Angular.

This, in my opinion, disrupts the very delicate balance Vue.js had between the diametrically opposed approaches of Angular and React, which is precisely what made Vue appealing to many of us in the first place.

DEV Community: Martin Sotirov

Vue 3 Composition API – The Wrong Solution To The Right Problem

Love at first Vue

RFC shit storm

The age-old problem of code reuse

The wrong solution to the right problem