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.
You can also use vuelidate which is good enough for most cases an smaller than veevalidate...
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.
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.
Very true. I wonder if anyone cared to fork the project just for typescript intergation 🤔
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
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.
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
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.
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.
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
Or the way how i described it - shamelessly plugging my own article :d
Don't worry, you should just use nuxt-plugin-axios, which wraps vue-plugin-axios for nuxt ;)
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.
Omg, "jQuery plugins" make my blood boil.
- here's a vanilla-DOM library
- do you have a version for jQuery?
- 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?
That's because so many people learned jQuery without learning JS, so they were scared of if. Dark times...
Well, I was so scared of jQuery, I just avoided the clientside all together until it left.
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.
What do you think about this approach?
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.
Thank you for clarification.
I think it's too small and blurry for me to read.
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.
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?
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.
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
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.
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.
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.
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.
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.
Heh. I hadn't heard of that one, even though I've used axios. Will definitely stick with plain axios.
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
Wow! I had no idea adding axios would be so simple. I'm done with this "plugin". :P
Your examples are misleading as that is not the correct way to construct and load a Vue plugin
Can you provide a working/correct example?
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 = ....
Vue.prototype.$myMethod = ...
So I would argue there isn't a big difference. Just use it with care.
I'm not sure what you mean. Could you explain?
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.