Regression: loading state when navigating between components

from 🐛 #ajax config not reliably implemented for consecutively added components Active

The problem is due to Redux createAPI() caching requests to xb/api/form/component-instance -
Any component form visited the first time will work.
If the component form is revisited in the same page visit, it will return the cached version which does not have the same selectors as those in drupalSettings.ajax and the ajaxification of elements such as "Add media" does

In other words, the forms loading quickly was a side effect of the problem that resulted AJAX being broken on repeat visits. By skipping some of the work necessary for the form to function, it was able to appear faster.

Even prior to #3520971 the first visit to any component instance form had this loading process, but it probably didn't feel like much of a performance lag because it usually occurred when the component was added to the layout.

If we want to have repeat visits to the same form load at speeds comparable to when they were not being fully initialized, some approaches come to mind, none of which seem like slam dunks. Note that the perceivable wait is not due to the AJAX initialization in JS, but the back end rendering a form with the expected selectors.

• Component instance forms are not destroyed if a new one is loaded, but instead hidden, and then un-hidden if their component is selected. The risk of duplicate IDs alone makes this risky, but there could be ways around it.
• Override the AJAX system so previous selectors are cached and perhaps indexed by form build id so if the form returns the selectors in the Redux-cached version are used instead of the fresh ones calculated by the form build process
• During the render process, identify component forms that have selectors targeted for processing by drupalSettings.ajax and flag these as the only ones to not be cached by Redux. This wouldn't eliminate the form-reloading altogether, but it would make it so it only happens on forms that require that additional processing.

This is a performance regression which belongs under bugs: https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... → . If it was clear that there was a performance regression and it was agreed upon as a trade-off, we would have opened a follow-up to fix this, which probably would have been a task. Usually this wouldn't be as critical but since this impacts one of the most commonly used tasks in the builder, it suddenly matters a lot.