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