User tests: Successful: Unsuccessful:
PR for Issue #30288
As explained with the issue at hand, the choices.js provides support for a render limit of the options and a search results limit, the first is much more important.
build/media_source/system/js/fields/joomla-field-fancy-select.w-c.es6.js
now can use render-limit
and results-limit
attributes to set searchResultLimit
and renderChoiceLimit
options for choices.js;libraries/src/Form/Field/ListField.php
now can properly add the renderLimit
and resultsLimit
attributes from layout;layouts/joomla/form/field/list-fancy-select.php
can now add the render-limit
and results-limit
HTML attributes to the element from the layout set renderLimit
and resultsLimit
field properties.Alternative solution
Since the issue we're trying to solve is the slow initialization for large lists, we can simply replace searchResultLimit
with renderChoiceLimit
with the same value of 10 in build/media_source/system/js/fields/joomla-field-fancy-select.w-c.es6.js
. The user would expect a search to take some time, but an initialization cannot take 2-3 seconds per field. This however won't give developers much flexibility.
extensionName.xml
and add this field in any <fieldset>
<field
name="fancy-select"
type="List"
label="List Demo"
default="5"
renderLimit="5"
resultsLimit="15"
layout="joomla.form.field.list-fancy-select">
<option value="0">zr</option>
<option value="1">zr 1</option>
<option value="2">zr 2</option>
<option value="3">zr 3</option>
<option value="4">zr 4</option>
<option value="5">zr 5</option>
<option value="6">zr 6</option>
<option value="7">zr 7</option>
<option value="8">zr 8</option>
<option value="9">zr 9</option>
<option value="10">ze 10</option>
<option value="11">ze 11</option>
<option value="12">ze 12</option>
<option value="13">ze 13</option>
<option value="14">ze 14</option>
<option value="15">ze 15</option>
<option value="16">ze 16</option>
<option value="17">ze 18</option>
<option value="18">ze 18</option>
<option value="19">ze 19</option>
<option value="20">zt 20</option>
<option value="21">zt 21</option>
<option value="22">zt 22</option>
<option value="23">zt 23</option>
<option value="24">zt 24</option>
<option value="25">zt 25</option>
<option value="26">zt 26</option>
<option value="27">zt 27</option>
<option value="28">zt 28</option>
<option value="29">zt 29</option>
<option value="30">zt 30</option>
</field>
Large lists are initialized extremely slow, also the initial resultsLimit
of 10 was not enough. Imagine more than 10 Roboto font family styles, or much more articles that contain a certain keyword / combination of keywords.
Much faster initialization, also more flexible PHP extend possibilities.
Yes.
Status | New | ⇒ | Pending |
Category | ⇒ | JavaScript Repository NPM Change |
Labels |
Added:
NPM Resource Changed
?
|
Category | JavaScript Repository NPM Change | ⇒ | JavaScript Repository NPM Change Libraries |
Category | JavaScript Repository NPM Change Libraries | ⇒ | JavaScript Repository NPM Change Layout Libraries |
Title |
|
I tested, 20ms improvement in loading time. but when I save the module settings it doesn't save the item when set to blank. and list still shows all items
I have tested this item
I tested, 20ms improvement in loading time. but when I save the module settings it doesn't save the item when set to blank. and list still shows all items
@mqueme I tested the mod_articles_news
with the above sample field and I confirm that after I save module settings with blank value, it will reset to first item in the list, which is something probably choices.js
script does because the rendered select on which the script initialize also sets the first item as checked.
I believe this is a non-issue. Anyone else have an opinion on this?
I confirm that after I save module settings with blank value, it will reset to first item in the list
it is correct behavior of <select>
form input, you have first item <option value="0">zr</option>
that will be selected by default if there no value
That behavior is expected especially if you want your form field to force the end used to use a value. For instance SCSS mixins/styles cannot work with blank values, $font-size
or $line-height
must be valid.
In other cases you can work with blank values for your form fields, you can simply add a new <option value="">None</option>
it will be able to do that.
It's up to the developer to decide on his/her extension how the form field of type="List"
should work.
Do you guys think we need to implement choices.js removeItemButton
option for cases where the null value is an option? (<option value="">None</option>
)
I'm also thinking of a way to check the first CHOICE and set this instance option automatically based on the value. (NULL => true, notNULL => false), what do you guys think?
I think it should accept null values, the current option has an x to remove the selected value which implies clearing the field. But saving it put the value back which makes it very confusing.
I not very like that idea. choices.js mimic behavior of <select>
input.
<select>
does not have any "removeItem" option, however if someone need it in custom field, he/she always can create a custom layout and do whatever he/she want
Why didn't you say so? Should I follow up on @HLeithner commit? it seems logical to me.
This PR is obsolete. Will commit a new one soon.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-03-05 16:02:27 |
Closed_By | ⇒ | thednp | |
Labels |
Added:
?
|
Please fix coding style: https://ci.joomla.org/joomla/joomla-cms/35972/1/8