[#33773] - [4.0] Repackage the js of fancy select field
- Closed
- 27 Jul 2021
- Medium
- Build: 4.0-dev
- # 33773
- Diff
- dgrammatiko:—repackage-choices—4.0-dev
User tests: Successful: Unsuccessful:
Pull Request for Issue # .
Summary of Changes
- Remove the choices.js from the vendor folder
- Use
importin the fancy select field
Why?
Well, custom elements (and Web Components) are better if they don't depend on other scripts, eg append the HTML markup and the script element should be the only step for using them.
Also, personally, I'm very worried that the library is already abandoned and shipping it in the vendor folder the project creates the same situation that existed with chosen. Let's not do the same mistake. By using import to utilize choices we are encapsulating the whole thing ONLY in the fancy select script source and thus someone could swap the library or completely rewrite the custom element without any dependency. In short, it's more future proof this way...
Testing Instructions
Apply that patch (needs npm ci
Check as many fancy select (the one with the search) in as many edit forms as possible
Actual result BEFORE applying this Pull Request
Works
Expected result AFTER applying this Pull Request
Works, 1 HTTP request less (but this PR is not about reducing the HTTP requests, HTTP3 is already here and the number of requests is completely irrelevant for performance)
Documentation Changes Required
No
@Fedik are you ok with this one?
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Repository NPM Change JavaScript |
| Labels |
Added:
NPM Resource Changed
?
|
||
Developers may want to use somewhere in their extension.
That's what I want to prevent. The script is abandoned so if Joomla ships with it will end up with the same mess as chosen:
We already ships it, no way back
Although I'm totally against this as it's very bad to ship dead code, I've reverted that part, so the script will be available in the vendor folder.
I have tested this item
The fancy select fields I tried still work after applying the patch. I was rather expecting the vendor choices to disappear from the source but it is still there
<script src="/j4test/media/vendor/choicesjs/js/choices.js?9.0.1" defer data-asset-name="choicesjs"></script>
I checked that it is not being used for this test (it is not) and guess some other component must be loading it - ->usePreset('chocesjs') is used in a couple of places.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33773.
must be loading it - ->usePreset('chocesjs') is used in a couple of places.
yea can be,
@dgrammatiko please check where fancy select is included,
and change ->usePreset('chocesjs') to ->useStyle('chocesjs')
| Category | Repository NPM Change JavaScript | ⇒ | Repository NPM Change JavaScript Layout |
The file layouts/joomla/form/field/tag.php also seems to need ->useStyle('choicesjs') on line 129.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33773.
I think that ->useStyle('choicesjs') needs to be removed everywhere (in atum). The choices.css is in atum/css and the choices.js is now in joomla-field-fancy-select.js - so calling choicesjs just loads the js file from vendor/choicesjs but it is not used. I am a bit out of my depth here!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33773.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-07-27 22:32:21 |
| Closed_By | ⇒ | dgrammatiko |
Well, that won't happen for J4 then
Yes and no.
Even if you embed the choicesjs in to the custom element, the choicesjs should be available as standalone asset.
Developers may want to use somewhere in their extension.