loading...

Let's talk about an unnecessary but popular Vue plugin

heftyhead profile image heftyhead ・3 min read

A few days ago some news about a popular npm package containing malicious code went viral. The whole incident is a reminder that we should think twice before adding another package to our dependencies.

It also reminded me of an unnecessary Vue plugin that I’ve seen pop up a few times. Vue‘s gentle learning curve makes it a popular choice with beginner developers, for whom it is even harder to figure out what to write themselves and what to install.

The offender

The package/plugin that I want to talk about is vue-axios. If you google “vue axios” it’s the first result. And I think that’s the main reason of it's popularity.

GitHub logo imcvampire / vue-axios

A small wrapper for integrating axios to Vuejs

vue-axios

A small wrapper for integrating axios to Vuejs

How to install:

CommonJS:

npm install --save axios vue-axios

And in your entry file:

import Vue from 'vue'
import axios from 'axios'
import VueAxios from 'vue-axios'
Vue.use(VueAxios, axios)

Script:

Just add 3 scripts in order: vue, axios and vue-axios to your document.

Usage:

This wrapper bind axios to Vue or this if you're using single file component.

You can use axios like this:

Vue.axios.get(api).then((response) => {
  console.log(response.data)
})
this.axios.get(api).then((response) => {
  console.log(response.data)
})
this.$http.get(api).then((response) => {
  console.

Let’s see what a plugin with 1000+ Github stars and 23,000 weekly downloads does. We can start by reading a description:

Usage:

This wrapper bind axios to Vue or this if you're using single file component.

There's also a code example which makes the use of the plugin even more clear:

Vue.axios.get(api).then((response) => {
  console.log(response.data)
})

this.axios.get(api).then((response) => {
  console.log(response.data)
})

this.$http.get(api).then((response) => {
  console.log(response.data)
})

Basically, this package allows you to import axios once and then use it in every component.

It’s actually quite useful. Not only don't you have to import axios in every component but also you can create an axios instance with a custom config and use it in all of them. However, it’s not really mentioned in the plugin's description, therefore I’m not sure if people installing the plugin are even aware of that.

An alternative

We determined that this plugin can be really useful. So what is the problem? Let's code the same functionality without using the plugin:

import Vue from 'vue'
import axios from "axios";

Vue.prototype.$http = axios;
Vue.prototype.axios = axios;

Let's compare it with the code required to configure the plugin:

import Vue from 'vue'
import axios from 'axios'
import VueAxios from 'vue-axios'

Vue.use(VueAxios, axios)

As we can see it takes the same amount of lines to write the whole functionality ourselves as it takes to configure the plugin.

Let's finish by showing slightly supercharged version of this approach of using axios with Vue:

import Vue from 'vue'
import axios from "axios";

const instance = axios.create({
  baseURL: 'https://myapi.com'
});

const instanceUserApi = axios.create({
  baseURL: 'https://userapi.com'
});
instanceUserApi.defaults.headers.common["Authorization"] =
  "Token" + localStorage.getItem("authToken");

Vue.prototype.$http = instance;
Vue.prototype.$httpUserApi = instanceUserApi;

We can create several axios instances each with a different configuration. Not only the plugin doesn't provide any value but it also is less flexible than our code. Just to make it clear the plugin allows you to create many axios instances by passing an object during configuration.

The difference and the excuse

As described in this Github issue:
the different between Vue.prototype and vue-axios? #18

The plugin makes properties(axios and $http) immutable. Which for some may be an advantage over approach described in the previous paragraph. Nevertheless, I'm quite confident that the significant majority of developers using this plugin doesn't really care about immutability.

Conclusion

Vue-axios plugin does what it's description says. There's no dishonesty or anything malicious here in my opinion. Just some uninformed developers that don't think twice about what they add to their projects.

What do you think about such small plugins/packages?
Do you think that creator of such plugins should disclose the alternative?

Discussion

pic
Editor guide
Collapse
sduduzog profile image
Beautus S Gumede

Unfortunately I feel it might be very popular to beginners. People who learn from videos, blogs first before official docs.

I've had a different but similar scenario with VeeValidate. Unlike vue-axios, it offers so much more. It has so many useful features. But it comes at a price, its bundle size, which is larger than vue itself.

A plugin like VeeValidate though can be avoided/skipped in favour of just regular expressions and v-bind tricks.

Collapse
rhymes profile image
rhymes

You can also use vuelidate which is good enough for most cases an smaller than veevalidate...

Collapse
sduduzog profile image
Beautus S Gumede

I started with it. But it doesn't play fair with typescript. Issues filed on the repo and PRs submitted as solutions but the repo owners also didn't meet devs halfway. On top of that, the site that introduced me to VeeValidate had a section after its intro that rants about the latter. Here just scroll to the last section.

Thread Thread
rhymes profile image
rhymes

Read the rant, he does have a point but I feel like also TypeScript can be a burden on maintainers that don't know/use/like it. He should have probably accepted the patch after making sure that the contributor was available on maintaining TS support from then on.

Thread Thread
sduduzog profile image
Beautus S Gumede

Very true. I wonder if anyone cared to fork the project just for typescript intergation 🤔

Thread Thread
rhymes profile image
rhymes

It's always tricky. Everytime you accept a big patch you're also going to maintain it in the future. If you fork a project like this because of the lack of a "small" feature, you're also going to need to keep it in sync, updating the types definition everytime there's something new.

There's no perfect solution

Collapse
dinsmoredesign profile image
Derek D

I use both VeeValidate and Vuelidate on several production apps. I love that Vuelidate is model-based and not DOM-based... But it's significantly harder to use for more complex things. The documentation for anything past the basics is utterly worthless and they keep changing validators so that, apps that worked just fine in the past, now fail validations all over the place if updated because of changed behavior.

Because of this, I've mostly converted back to VeeValidate. I'd prefer to stick with Vuelidate, as its API makes more sense IMO and it's ridiculously simple to add custom validations to... But inconsistencies in functionality and the fact that writing conditional validations can be an utter mess has me saying away from it. I wish there were more good options out there, honestly.

Thread Thread
sduduzog profile image
Beautus S Gumede

After trying both for my side project. I ended up with just this

A little bit more work but I believe it's worth it

Thread Thread
rhymes profile image
rhymes

I don't agree entirely but I can understand your frustration.

Lately though I'm thinking more about the cost of open source from all sides. Vuelidate is a perfectly fine library and as you say, its API is nice and users can use it easily. But it has limitations, because it's aimed at simple scenarios that can be mapped on top of it. If you want full control you'll end up looking for alternatives.

This doesn't make VueValidate bad, it just makes it geared to some cases but not all. At the same time as you said you have VeeValidate which is more complicated to use but can scale a little better than Vuelidate. Unfortunately it's also massive in size.

I wish there were more good options out there, honestly.

Definitely, or maybe VeeValidate needs to be split up in plugins? Don't know, just an idea.

Thread Thread
rhymes profile image
rhymes

The issue with custom tailored validation logic (reminds me of the hacks on top of jQuery back in the day :D) is that it doesn't scale as in: it will get complicated quickly, especially if your validation is complex (and mine was, that's why I had to leave Vuelidate for VeeValidate) or if you don't want to start from scratch everytime you start a new app.

I'm not saying your case should use a library, but that a library has its purposes.

Again, there's no perfect solution :D

Collapse
lostdesign profile image
André

Or the way how i described it - shamelessly plugging my own article :d

Collapse
qm3ster profile image
Mihail Malo

Don't worry, you should just use nuxt-plugin-axios, which wraps vue-plugin-axios for nuxt ;)

Collapse
erainey profile image
Eric Rainey

Some great insights here and as far as your questions go, my opinions are:

1) Small plugins/packages can be really useful, and I think this aspect of web development is a carry-over from the jQuery days where you could easily import a script to handle some kind of UI feature without writing your own. It has an appeal in the sense that it is a time saver as well as having some sort of "credibility" as a published open source tool that others have used in their own projects.

However, this leads to relying on plugins being a crutch, and I think that it can hinder developers from improving their skills by leaning on them too much. I know when I first started, I tended to use these scripts a lot, and became frustrated when they didn't do exactly what I needed it to do. This led me to start writing my own solutions and I think that exercise is what helped me improve my own skills.

2) I don't think the onus of offering alternatives should be placed on the plugin developer. Most well-curated plugins have some kind of documentation, and a lot of the times, it has some high-level description of what it does, and perhaps why it was created in the first place. It's often phrased like a sales pitch, but I can understand why. The plugin developer wants people to use their tool; after all, that's why they open sourced it in the first place, right? I think a "buyer beware" policy should be followed by any who want to use these types of tools.

Collapse
qm3ster profile image
Mihail Malo

Omg, "jQuery plugins" make my blood boil.

Like:
- here's a vanilla-DOM library
- do you have a version for jQuery?

Or even:
- here's a library of pure functions that don't touch the DOM.
- so modern, so modular! But how do I use it with jQuery?

Collapse
maciek134 profile image
Maciej Sopyło

That's because so many people learned jQuery without learning JS, so they were scared of if. Dark times...

Thread Thread
qm3ster profile image
Mihail Malo

Well, I was so scared of jQuery, I just avoided the clientside all together until it left.

Collapse
lkmist profile image
L-K-Mist

Excellent subject-choice! As a novice, I've been particularly guilty of this "Plugin First" approach, only to find that wrapping my head around the use of the plugin is often no time-saver compared with the unwrapped lib.

Collapse
moopet profile image
Ben Sinclair

There's a module for Drupal 7 called jquery_dollar. It contains the usual Drupal boilerplate and boils down to this:

var $ = jQuery;

It is (was?) very popular, because people cargo-cult it in and don't understand anything about scope.

There was an app called "Less.app" (I think) that ran on a Mac and watched a directory for changes, and then recompiled the CSS from Less. It did what "Sass watch" does but for Less, and it was totally, utterly and in all ways unnecessary. It sold for 99 cents and was immensely popular, because obvious cargo-cult and shiny Mac reasons.

Every time a new package manager comes along, there's a scramble to re-write everything that's ever been made in a different language, driven mostly I think by people's desire to be able to say they're the maintainer of a project which was already doing quite alright and didn't need a makeover, and hey now it's trailing a version behind and has all-new bugs.

I think wherever you look you'll find these sort of examples. I think you always will. It's not really anyone's failure if they use trivial anti-packages like this, it's just because there's so much to learn and not enough time to question every step you read in most of the tutorials you find online.

Collapse
romanpaprotsky profile image
Roman Paprotsky

Alt text of image
What do you think about this approach?

Collapse
heftyhead profile image
heftyhead Author

In my opinion, it's a valid approach. Declaring global variables is generally considered a bad coding practice. However, I feel like if you don't abuse it and you are not working on a really big project it doesn't matter as much.

I think that the advantage of using the prototype approach is that usually, you want to make API calls in relation to the component life cycles and events. So making axios available only by components code ensures that API calls are made only in the right moment(you can still pass axios as an argument to a function or a class). This is a quite broad topic so you can easily argue that what I wrote is not always true. Nevertheless, I hope that you can see some advantages of using the prototype approach.

Collapse
romanpaprotsky profile image
Roman Paprotsky

Thank you for clarification.

Collapse
moopet profile image
Ben Sinclair

I think it's too small and blurry for me to read.

Collapse
workingwebsites profile image
Lisa Armstrong

Plugins: as many as you need, but no more than necessary.

Before looking for a plugin, I ask myself:

1) How do you code it yourself?
Learn something!

2) Is it worth the time to learn a fix?
I usually put a time limit, if I'm not getting somewhere in 30 minutes with this problem, move on.

3) Will this plugin fix other problems?
I recently used a date plugin because dates are nasty to work with. Life got better.

4) Does the plugin really save time?
If you spend hours fighting with a plugin, find another solution.

5) How many moving parts does this project have, should we add more?
The more plugins you have, the more likely there is to be a conflict... with code you didn't write.

Collapse
alexparra profile image
Alex Parra

For the sake of decoupling, I think it’s best to only use this.$http even if mapped to axios.
If ever you need to change the library, you won’t need to change all the components (or have a misnomer).
Even better, create an API module that exports specific methods that represent endpoints which in turn use the axios instance.

Collapse
whitebookmark profile image
Rein

Oh wow, I never noticed that before. After reading this post I have removed VueAxios from my project, really I don't need it when I am using "this.axios.get..." everywhere, 2 lines of prototype solved it for me.

Thank you for sharing this info

Collapse
nektro profile image
Meghan (she/her)

While I would typically agree that a plugin for such a use case, the second block of code is much more in line with how I would want the code to look, from a code quality perspective. Dynamically modifying a prototype you dont control in a system that doesnt actively type check or error/warn for overwriting these properties is a lot worse than the flow of having an extension and registering it to the global object.

Collapse
leob profile image
leob

I agree with your last sentence - authors of this kind of pretty trivial package, even when they create their stuff with the best of intentions, would do good to point out the alternative to using their package, rather than selling it as the best thing since sliced bread (which, I'm hasty to add, the author of vue-axios is NOT doing). Authors doing so are benefiting their potential users by educating them.

Collapse
dinsmoredesign profile image
Derek D

Couldn't agree with this article more. I've seen Vue Axios used so much, I'm just confused as to why anyone needs it. It doesn't really make setting up Axios any easier and it's just unnecessary.

Collapse
tommcclean profile image
Thomas William McClean

Just went looking into my personal project, thankfully I am using the base axios package. However I did notice I am using vue-lodash. I wonder if that is a similar example.

Collapse
jsn1nj4 profile image
JSn1nj4‍‍👨‍💻

Heh. I hadn't heard of that one, even though I've used axios. Will definitely stick with plain axios.

Collapse
_wost profile image
William Østensen

At work, we create an Axios object, and just do all the API work in VueX - that way we don't have to worry about writing the axios element all over the code! :D

Collapse
molemann85 profile image
moleCuleFFF

Your examples are misleading as that is not the correct way to construct and load a Vue plugin

Collapse
puritanic profile image
Darkø Tasevski

Can you provide a working/correct example?

Collapse
renzos profile image
Renzo

It's not claiming to be a 'plugin'. But if you want to attach a utill, he says it's fine to use the base lib and just attach it to the prototype. And I tend to agree in the case of Axios.

Vue.use() just checks if it wasn't already registered and calls the install() method. And in the docs (vuejs.org/v2/guide/plugins.html) is mentioned; "want to bind something to the instance?" -> Vue.prototype.$myMethod = ....

So I would argue there isn't a big difference. Just use it with care.

Collapse
heftyhead profile image
heftyhead Author

I'm not sure what you mean. Could you explain?