Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
v3.0 Roadmap #963
Vue-Multiselect v3 Roadmap
Reasoning for the v3 Rewrite
The current 2.x version has become pretty complicated, especially on the template side. The way it currently behaves, makes it very hard to implement any accessibility improvements. Additionally, it limits the customisation options, especially on the interaction part. Adding more slots and props is sadly not a reliable long-term solution, since it will lead to further increased complexity and thus making it even harder to maintain.
Goals for the Rewrite AKA the New Architecture
The idea behind v3 is to simplify the library by breaking it apart into smaller, self-contained components responsible for fragments of the functionality (like options list, input, container, selected options), which can be replaced with developer-provided components for more control. To accomplish this, the whole “logic” part has to be extracted into an unopinionated UI-free component. This can be done by constructing a renderless component that exposes its state and methods to child components through scoped slots.
Then, the renderless component along with the smaller components can be composed and wired together to form the component that is required be the developer.
This should make it possible for developers to have almost complete control over the component and add their own functionalities on top of it, without requiring any changes within the library itself. This should lower the amount of feature-requests and thus help reduce feature-creep.
For example, you will be able to put a searchable table inside the dropdown. Or not have a dropdown at all and make it permanently open.
Here’s the visualization of the new architecture.
If this looks complicated to you – don’t worry. To keep the same, easy-to-use/just-works experience known from the current 2.x version, the rewrite will also ship with a default composition that mimics the current feel and look as well as API interface you got used to. That means, as long as you import the component
This brings us to the breaking changes / migration part.
Breaking Changes / Migration from v2.x
Due to shipping with a pre-existing, default composition that mimics the current look and feel of the v2, there shouldn’t be that many breaking changes when migrating to the new version. Ideally, you should be able to just bump the package version and everything should work as it did, as long as you used the most popular features.
Possible breaking changes
All the changes are available on the
How you can help?
For the questions part, a survey will follow shortly.