Upgrade to select2 4.0

[jhawthorn]

select2 4.0 is out (so is a new version of select2-rails)

[jhawthorn]

Started looking into this, and although there are some significant improvements in select2 4.0, there are a number of incompatibilities (and maybe some style issues) that make the upgrade non-trivial.

I'll revisit this again later, maybe after the select2 4.0.2 release

[pusewicz]

@jhawthorn 4.0.2 is already available!

[jhawthorn]

I'm no longer sure it's a good idea for our project to upgrade to select2 4.0.3. I can't entirely rule it out, but it would be a significant investment (both from me and stores/extensions upgrading) for questionable, and maybe negative benefit.

Select2 4.0 has significant API changes. See for example what it takes to change variant_autocomplete.js.coffee to use select2 4.0.

• The signature of processResults has entirely changed
• The signature of data has entirely changed
• initSelection can be made to work with modifications, but actually generates warnings that it is deprecated without replacement.
• formatSelection and formatResult have been replaced with templateResult and templateSelection
  • They take different arguments
  • Output is escaped by default, breaking templates. It can be configured not to be escaped, but Select2.util.escapeMarkup is no longer provided.
  • formatResult is initially called with the data {loading: true, text: "Searching...."}. What?!
• Automatic expanding width to match the existing element no longer seems to work

Those are all frustrating and will be an issue for every single one of our existing select2 components. But there's a greater issue that I think makes this a non starter:

• select2 can no longer be tied to an <input

There is supposed to be a compatibility layer for this but it does not work at all. Select2 now expects to get a <select> element even when doing ajax (which I don't believe is even supported in 3.5). This is a fair bit more awkward because we have to provide at least the <option> for initial selection.

Any element (solidus, extensions, or stores) using variant_autocomplete or any of our other autocomplete components will have to change their markup, and will have no way of being backwards compatible (which is very bad for our extensions).

On top of that. I'd suggest that the library's future is uncertain. There have been under 10 commits since last June, with the project seeking new maintainers.

So IMO we should stick with select2 3.5 for the time being, possibly improving the old style since that was one of the main issues with it. We should also consider moving off of select2 entirely as upgrading would be as much of a breaking change as migrating entirely. Unfortunately, I know of no equivalent replacements.

[jhawthorn]

Closing as there's nothing actionable here. I no longer think upgrading to select2 4.0 would be a net positive for our project.

[alexweissman]

@jhawthorn I went through a similar experience, and was very frustrated to find that Select2, as well as all of the major alternatives, do not seem to be maintained or in active development.

Fortunately, Kevin has added me as a maintainer/developer on the Select2 repo which means that I now have the ability to merge PRs, push to the repo, and create releases. Since it seems like you also depend on Select2 for the time being, would you and your team be interested in helping to resurrect the project?

I've set up a room on my chat server (https://chat.userfrosting.com/channel/select2) as a place to discuss Select2 and its future, for the time being.

[pusewicz]

An alternative is to go with https://github.com/harvesthq/chosen.

[alexweissman]

Thanks, I am aware of Chosen and Selectize, but I was under the impression that they won't be doing any further development either. For example, Chosen's release notes for 1.7.0:

From this version on, until further notice, no new features will be added, so pull requests for features will not be accepted. However, pull requests for bugfixes are still very much appreciated.