Updated: Comment 0
drupalSettings.states never clears, it's very noticeable on the views UI where #states is used all over the place. It gets slower and slower to open modals. Because all the rules just adds up in drupalSettings.states (It's easy to arrive to 120 rules after opening a few modals). and they all get processed every time even if the elements don't exist on the page.
Also, very slow. Event delegation on the views UI modal reduce the time it takes to open a modal by 1 second (!) on desktop (from 3.8s to 2.9s).
This patch move the #states configuration away from Drupal.settings and into a
data-drupal-states attribute on the relevant form element (it's data-drupal-states because data-states sounds like it'd be an easy naming confilct).
I had to move the drupal_process_states() call before drupal_render to add the attributes from this function.
The JS change is really straightforward, instead of getting the values from Drupal.settings it takes it from all the elements having a data-drupal-states attribute. The #states configuration is serialized in json inside the attribute. It's legit from a HTML standpoint, anything goes inside data-* attributes.
User interface changes
Original report by @nod_
|#14||states_for_type_item_broken-1589176-14.patch||1.01 KB||Wim Leers|
|PASSED: [[SimpleTest]]: [MySQL] 59,774 pass(es).|
|PASSED: [[SimpleTest]]: [MySQL] 58,930 pass(es).|
|PASSED: [[SimpleTest]]: [MySQL] 36,601 pass(es).|