Vue is famed for its ease of use and simplicity. It achieves these qualities, in part, by having a focused and small API without too many extraneous features.
That said, users and maintainers are always thinking about potentially useful new features. This article discusses five of the most requested features from Vue's GitHub issue board.
- Support for iterable protocol with v-for
- Multi-root templates (fragments)
- Reactive refs
- Custom v-model modifiers
- Package for custom renderers
It's good to be aware of these feature requests, as some will make their way into coming versions of Vue, while the ones that don't may help you better understand the design of Vue.
1. Support for iterable protocol with v-for
What is it?
When you think of iteration, you'll most likely think of arrays. ES2015 introduced the iterable protocol which, when implemented, allows for any kind of object to be iterated using for...of. ES2015 also introduced new iterable data types like Map and Set.
Currently, Vue's v-for directive can iterate arrays and plain objects, but not other iterable objects or data types. If you're using a Map, for example, and you want to iterate it with v-for, you'll first have to convert it to an array or plain object.
Note: maps, sets, and other new iterable data types are not reactive, either.
Why do users want it?
Since iterable objects and data types are officially part of the JavaScript language now, it's inevitable that applications will utilize them for the benefits they offer.
If Vue is used as the UI layer for such an application, these objects and data types either can't be iterated in the template or will need to pass through transformation functions.
Will it be added?
Maybe. The issue has been closed on GitHub, as the maintainers weren't convinced that iterable objects and data types would commonly be used for UI state. Also, making iterable objects and data types reactive would take considerable work.
However, Vue's observation system is to be refactored in version 2.x-next, which would be the ideal time to implement this feature.
2. Multi-root templates (fragments)
What is it?
Currently, Vue has a limitation where templates require a single root node. That means this is valid:
<template> <div/> </template>
But this is not:
<template> <div/> <div/> </template>
Some Vue users are requesting multi-root templates, especially now that the feature has been added to React.
Why do users want it?
If you want your component to render child nodes for some parent element, you'll need to add a wrapper to comply with the single-root restriction:
<template> <div><!--Need to add this wrapper--> <child1/> <child2/> ... </div> </template>
Having a wrapper in the structure will interfere with the requirements of certain HTML or CSS features. For example, if you have a parent element with display: flex, having a wrapper between the parent and children won't work.
<template> <div style="display:flex"> <!--This pattern won't work because of the wrapper:/--> <FlexChildren/> </div> </template>
Will it be added?
According to the maintainers, the way the virtual DOM diffing algorithm works makes this feature difficult to implement and would require a major rewrite. As such, this feature is not on the roadmap for development.
3. Reactive refs
What is it?
An essential design aspect of Vue components is that they must be isolated and communicate by props and events. However, sometimes you need one component to be able to mutate the state of another. For example, you may want a form component to switch on the focus of a child input component.
The solution is to use refs, which give a component an escape hatch into another component's data model. However, when accessed via refs, the component's data model is not reactive so it can't be watched or included in a computed property. Reactive refs would allow it to be.
Why do users want it?
Components normally communicate through props and events, and only in a parent/child relationship. For a parent component to track a child component's data, the child must emit its state changes via events. This requires the parent to have a listener, a handler, and local data properties for storing the tracked state.
For an example of this, imagine a parent form component tracking the state of a child input's "valid" state:
<template> <form-input @valid="updateValidEmail"> </template <script> export default { data() => ({ emailValid: false }), methods: { updateValidEmail(value) { this.emailValid = value; } } } </script>
This code works fine. The only problem is that every single child input in the form needs similar, unique code. If the form has 10's or 100's of inputs, the form component will become massive.
Using reactive refs, the parent would not need to track the child and could simply watch its state with a computed property, reducing excessive code.
<template> <form-input ref="email"> </template <script> export default { computed: { emailValid() { // Currently this won't work as $refs is not reactive this.$refs.email.isValid; } } } </script>
Will it be added?
While it is a highly requested feature, there are no plans to add it. One concern is that the feature violates good component design. Refs are meant to only be a last resort when the props/events interface can't be used. Making refs reactive would allow for anti-patterns where refs were used instead of events.
Custom v-model modifiers
What is it?
You can use the v-model directive to create two-way data bindings on form inputs:
<input v-model="message"/> <!--Message automatically updates as the input is used--> <p>Message is: {{ message }}</p> <script> new Vue({ data: { message: null } }); </script>
v-model is syntactic sugar over a prop and event listener.
Several modifiers are available to transform the event. For example, the .number modifier, used like v-model.number="num", will automatically typecast the input as a number. This is useful because even with type="number" on the input, the value returned from HTML input elements is always a string.
This feature request is to allow custom v-model modifiers defined by users.
Why do users want it?
Let's say you wanted to automatically format a Thai phone number as a user typed it into an input, for example, typing "0623457654" would be transformed to "+66 6 2345 7654". You could write a custom modifier, say, .thaiphone, and use it on your input. Easy.
Without this feature, either a computed property needs to be created for each input to perform the transform, or a custom input component needs to be created where the transform logic occurs before the event is emitted. Both of these options work but require additional code that seems easy to avoid.
Will it be added?
Unlikely. This and related issues have been closed by the maintainers who recommend the workarounds just mentioned.
Package for custom renderers
What is it?
Currently, Vue's renderer is hard-coded for HTML elements, as Vue was initially intended only for use on the web. The idea of this feature is to isolate the HTML renderer from the main Vue package.
Why do users want it?
Vue is now being used in non-web environments e.g. on mobile via projects like NativeScript. Isolating the renderer would make it easy for a library author to replace the HTML renderer with a renderer suitable for their chosen environment.
Vue.use(NonWebRenderer); new Vue({ render(h) => h('non-web-element', { text: 'Hello World' }); });
Will it be added?
Yes! This will be part of a larger change where many Vue internals will be split into separate packages with their own APIs, allowing this and other kinds of Vue custom builds. This change has been added to the Vue.js Roadmap and is slated for version 3.x.
By : Anthony Gore
#vue-js