Joomla-cms: RFC chosen.js

Created on 10 Aug 2016  路  10Comments  路  Source: joomla/joomla-cms

The version of chosen.js we use is 0.14 which is was released Jul 26, 2013
we made some small modifications to it but those modifications were included in a later release

The current version of chosen.js is 1.6.2 released 7 days ago. https://github.com/harvesthq/chosen/releases/tag/v1.6.2

Is there a specific reason we have not (are not) updating to this release.

Alternatively I have been looking at a replacement which is http://leaverou.github.io/awesomplete/ and it looks very impressive.

No Code Attached Yet

Most helpful comment

Reason is B/C, somwhere here already was discussion about it, couple years ago.
I would chose Select2 (https://select2.github.io/) for replace.

_Awesomplete_ it is the script for autocomplete, not for <select> styling, so not equal replacement 馃槈

All 10 comments

Reason is B/C, somwhere here already was discussion about it, couple years ago.
I would chose Select2 (https://select2.github.io/) for replace.

_Awesomplete_ it is the script for autocomplete, not for <select> styling, so not equal replacement 馃槈

I realise its not a 1:1 replacement but my thought is that with autocomplete you dont need the selet styling - perhaps

I think the previous discussion was #6161

@brianteeman the versions after the one that joomla is using expect different selectors which means b/c incompatibility for the existing scripts

Can we not fork the current one to get all the fixes and improvements and
just change the names in the fork?

Honestly if we are about to do something for this script I would choose a ECMA6 native script. Searching in the chosen repo there is a PR with that code, and I guess someone already has a select2 native version

I would choose a ECMA6 native script

Except we still support IE8, and if http://kangax.github.io/compat-table/es6/ is any good even without listing that browser specifically, the odds of that being a possibility right now are slim to none.

Can we not fork the current one to get all the fixes and improvements and
just change the names in the fork?

Honestly, if we're going to fork something third party just for the sake of pulling updates, we're better off developing it in house suited to our use cases. It's bad enough we've already got (undocumented, and no the inline code comments don't count here) hacks in other third party media libraries.

I would suggest sticking with what we currently have until J4.x, then we can move to something better or update what we currently have without core hacking it

Closed - thanks for the answers

Was this page helpful?
0 / 5 - 0 ratings