Preload WASM files for compiling code component previews

balintbrews → credited lauriii → .

@lauriii suggested this after investigating a performance bug report.

I wonder if we could/should do this in requestIdleTimeout instead so it doesn't impact the initial load time of the rest of XB
Although we could also use a fetchpriority of low and leave the browser to work it out

we have some prior art in \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\JsComponent::renderComponent albeit for modulepreloads

Although we could also use a fetchpriority of low and leave the browser to work it out

Something like that is what I had in mind.

Apparently this massively reduces load times on high-latency environments: 8–10 seconds → <3 seconds.

The code in the MR looks good, so I approved it (before seeing Wim's comments), but it seems questionable to me to be preloading 30MB of stuff (even with low fetch priority) before we even know the person wants to edit a code component. I wonder if we should delay this until there's some further indication of that, such as:

• Clicking "Add new component" (after which there's a bit of time for the user to enter a name for it)
• There already existing at least one code component (either as a real config entity or in auto-save)

React-dom has a preload function by the way, if we want to initiate this based on some client-side determined condition.

Since this MR only preloads for people with the "administer code component" permission, I'd be okay with this being merged as-is (once Wim's okay with it) and us discussing the above in a follow-up.

Also, we don't need these when the user first enters the code editor, do we? Since either it's a new code component, so we're using the sample code, or it's an exiting code component, so we're using whatever was previously saved, so in both cases, we already have previously compiled stuff we can show in the preview. Which means we don't need to execute the wasm code until the user starts typing something into the code editor. At which point, could we put a message in the preview area saying "Generating Preview..." or something like that if the wasm files haven't fully downloaded yet?

I agree with #12 and #13 ✨ Preload WASM files for compiling code component previews Active : An action on the UI would be better to use as a trigger for preloading the assets.

How close are we to introduce granular permissions to code components? If we are, I also agree that the current MR could go in, since it only impacts the "administer code component" permission.

#13 ✨ Preload WASM files for compiling code component previews Active :

Also, we don't need these when the user first enters the code editor, do we? Since either it's a new code component, so we're using the sample code, or it's an existing code component, so we're using whatever was previously saved, so in both cases, we already have previously compiled stuff we can show in the preview.

This sounds very sensible, but at the time of implementing that, I thought it was a good idea to always re-compile the first preview for these components to ensure consistency with the current compilation config. Now it seems unnecessary, however, we do additional compilation for the code editor preview only: we compile the slot examples into Preact components. (dangerouslySetInnerHTML is not supported on Fragment, so we compile the example HTML code for slots into proper Preact components.) If we were to switch to using the compiled JS for the code editor preview, we'd need to start storing that as well.

My recommendation for the (future) UI changes would be to use the toast and overlay that was introduced in 🐛 Auto-save changes from code editor get lost if you navigate out too quickly Active when the code editor opens, and the WASM assets are not available. If and when we decide to start using the compiled JS even for the first preview, we can still rely on this UI pattern, but not right when the code editor opens.

This is currently a several second latency, just a single time and then browser cached, and only for people editing code components. It doesn't need to block a beta. It's possible we'll manage to squeeze it in before beta anyway, but we don't need to track it for that.