We can connect you with highly skilled Vue developers to build your next web project or join your team remotely.
Skills we offer:
Get in touch to discuss your requirements!
Thanks to Vue’s reactivity model, it’s really easy to roll your own form validations. This can be done with a simple method call on the form submit, or a computed property evaluating input data on each change.
Using your form validation can quickly become cumbersome and annoying, however, especially when the number of inputs in the form increase, or the form structure gets more complicated e.g. multi-step forms.
Thankfully, there are great validation plugins for Vue like Vuelidate. In this article, we’ll be looking at how Vuelidate can be used to simplify:
We’ll also see how the Vuelidate-error-extractor plugin can be used to simplify error message display per input, or as an error summary above or below the form.
Vuelidate is data-model oriented, meaning validation rules are added to a validations object in the component definition, rather than being added directly to input elements in the DOM.
The structure must resemble that of the form object, but the number of validation rules can be dynamic and change depending on which fields need validation.
export default {
name: "FormComponent",
data() {
return {
form: {
name: "",
email: ""
}
};
},
validations: {
form: {
name: { required },
email: { required, email }
}
}
...
};
Here’s a live example:
A prop can take any form, from a simple string or number to a complex object. And even a Function.
This is exactly the idea behind Callback Props: a Function that gets passed as prop to a child component, so the child component can execute it whenever it wants (after a button is clicked, a form is submitted, an API request failed…).
Callback Props are the “React way” of passing actions from parent to children. They are functions defined by the parent that execute when something happens to the child component. They can also be used with Vue.js as a replacement for events.
There are several pros and cons to this approach. In this article, I will compare the two approaches and help you decide which is best for your projects.
The first time you read the amazing Vue docs you are presented with a simple communication pattern between components:
Here’s an example of using both a prop and an event in Vue to play with an input value:
Nuxt’s very opinionated when it comes to code structure. Its conventions can save you a lot of time making decisions. After one year using it on large codebases though, I’m glad there’s considerable wiggle room for customization. In this article, I lay out a few tips that have either simplified common code patterns or helped me better manage my large Nuxt codebases.
Bear in mind this article concerns Nuxt’s 1.4.x version. At the time of writing, work on a substantially revamped 2.0 version is already underway. Also, Nuxt is mostly known as a SSR toolkit, but it’s perfectly capable of building SPA apps as well. I like the fact that Nuxt offers a codebase organization standard for all Vue applications.
Nuxt’s latest release includes extendRoutes(), a way to add custom routes to Nuxt’s automatic route setup based on the pages/ directory. You can also bypass Nuxt’s setup entirely by using a routes index file. While you still need to use pages as the directory, you can add a index.js to it:
module.exports = [
{
name: 'my-route',
path: '/my-route',
component: 'src/pages/foobar.vue'
}
]
In nuxt.config.js, use this as your extendRoutes():
extendRoutes (nuxtRoutes, resolve) {
nuxtRoutes.splice(0, nuxtRoutes.length, ...routes.map((route) => {
return { ...route, component: resolve(__dirname, route.component) }
}))
}
Many, not all, mobile applications act as a client for viewing remote data that might typically appear within a web application. The most common way to consume and transmit data is through HTTP requests that communicate to remote web services or RESTful APIs.
If you’ve been keeping up with my Vue.js content, you’ll remember I wrote a tutorial titled Consume Remote API Data via HTTP in a Vue.js Web Application. In that tutorial, the web browser acted as the client and we used axios and vue-resource to make HTTP requests.
In this tutorial, we’re going to see how to make HTTP requests within a NativeScript application built with the Vue.js JavaScript framework.
Remember, NativeScript will create native Android and iOS applications. However, the web method towards making HTTP requests, as demonstrated in my previous tutorial, will still work. That said, we’re going to look at the NativeScript way to do business and revisit the alternatives.
Very few people write Vue components originally intending them to be open-sourced. Most of us start out writing components for ourselves - we have a problem, and then decide to solve it by building a component. Sometimes we find ourselves wanting to solve the same problem in new locations in our codebase, and so we take our component and refactor it a bit to make it reusable. Then we want to use it in a different project, and so we move it out into an independent package. And then we think “hey, why not share this with the world?”, and so we open-source the component.
On the one hand, this is great, it means a large and growing availability of open-source components out there for anyone working in Vue (a search for “vue” on npmjs.com turns up over 12000 packages).
On the other hand, because most of these components evolved from a specific situation, and not all of us have experience designing components for reuse across many environments, many of these components do not “play nice” with the Vue ecosystem.
What does it mean to “play nice”? At a high level, it means behaving in a way that feels natural to Vue developers, and that is easy to extend and integrate into any sort of application.
After exploring a wide range of open source components, here’s what I think goes into making a Vue component that plays nice:
