Include the preview HTML in the layout controller payload

I think this needs 📌 Support server side massage and validation of component prop form values Active

The intent here is purely a UX improvement, right?

i.e.:

• eliminate one request
• … a request that can only be made after another request's response has been processed by the client
• All to improve the TTI, right?

If so: why is this blocked on 📌 Support server side massage and validation of component prop form values Active ? What am I missing?

Having reviewed #3499550 in some detail (see [##3499550-13]) AFAICT this should land first and will then make #3499550's MR simpler.

The intent is partially performance but also it gets us closer to 📌 META: Conflict free concurrent editing Active

We need to do 📌 Support server side massage and validation of component prop form values Active first because it introduces the previewSlice

Commit ace768f6 has the work here on top of 📌 Support server side massage and validation of component prop form values Active

When that is in, we can rebase --onto origin/0.x and drop d78ade44

Also blocked on 📌 OpenAPI spec insufficiently precise for `LayoutComponent` Active which will make the diff here smaller

📌 Support server side massage and validation of component prop form values Active is in!

📌 OpenAPI spec insufficiently precise for `LayoutComponent` Active also landed.

Per #3499550-43: Support server-side massaging and validating of ComponentInputsForm values → , this blocks 📌 Discover cases where is no 1:1 map between field, prop and widget values Active .

@heyyo mentioned this in 📌 Improve backend API when lots of components Active

From slack

It looks like a POST request, why we need to post anyhting to backend when just loading the page ?

+1 — this seems like super low-hanging fruit!

7 e2e fails feels like real things

This is green

Added some nits but as usual this looks good, leaving at NR so Wim or others can still review.

So much awesome here — I did not expect this to help harden our end-to-end test infrastructure, but it's great to see that happen!

REady for another look

Looks splendid now, and apparently my request for clarification was raised by @larowlan ~2 months ago too, so he did it in this MR, which enabled him to close 📌 [PP-1] Consider renaming 'initialized' boolean in layout slice to 'postPreview'' Postponed 👍

This was only missing @bnjmnm's explicit approval of the MR for ui/src/components/form/inputBehaviors.tsx for

+    // Flag that we need to update the preview.
+    dispatch(setUpdatePreview(true));
      dispatch(setPageData(values));

This seems low-risk enough to just go ahead and merge this, especially considering @bnjmnm AFAICT already reviewed this MR (see #20).

📌 Get Options as buttons in Page Data form working Active seemed to unblock more things, so I landed that first. It conflicted with this. I tried to resolve it. Let's see what CI says.

This unblocked 📌 Replace the postPreview action with atomic equivalents Active ! 🚀