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.

The MR enables force refetch which initially loads the fast cached version that was satisfying but didn't work with Drupal Behaviors -- once the freshly requested version is available, it quietly replaces that the instant-but-useless version providing of it feeling fast and, well, actually working.

This introduces a bit of theoretical e2e trickiness as it means selectors can be available before the JS in the form works - but this is only an issue on repeat visits to a component and there's currently little to zero representation of that in e2e.

To anyone reviewing, be aware that - on a given page load - the first time opening the component instance form for a given component still takes time. That has always been the case as the Redux cache is warmed by that initial visit. Those revisits should be quick as the era prior to 🐛 #ajax config not reliably implemented for consecutively added components Active as this brings back to the behavior of getting the form it from the Redux cache when available... but with the key difference of theatcached form being replaced by a functional one ready.

This one would be best reviewed by somebody intimately familiar with both React, XB's use of React, Drupal behaviors and the AJAX system. Besides @bnjmnm that's only one person: @larowlan 😅

Tagging per @lauriii in #4.

Committed to 0.x

Very nice 😎

Automatically closed - issue fixed for 2 weeks with no activity.