Real-time preview for props changes of JS components

• Assuming we can get the updated prop value client-side, we can update the preview by simply targeting the <astro-island> element for this component instance, and updating its props attribute. The Astro island will then automatically re-render itself client-side based on the new props.

I forget the details of how our undo/redo functionality is implemented exactly (and I see we're missing docs for it other than a one-liner 🫣), but … AFAICT this would then have to add Component Source-specific logic to perform undo+redo. It'd need to check every affected component instance when undoing/redoing, check if it's provided by the js ComponentSource plugin, and then perform this alternative.
And if and only if there's zero other component instances affected, then that's all that's needed. But if there's >=1 component instance from another component source that needs undoing/redoing, we still need to talk to the server, because the server can only update the entire preview, not a subset.

(And I bet there's more complications.)

Is there a reason we don't include the preview HTML in the undo stack? Thereby allowing all undo operations (regardless of what kinds of components are on the page) to optimistically render before the server response?

Fair question. I suspect because "memory usage will go through the roof".

Tagging this as a beta blocker, because we want early adopters of the beta able to run XB in production, including under potentially heavy server load.

I think @effulgentsia implies with "heavy server load" that he wants Content Creators using XB to have a good experience, which implies a low-latency experience, even when latency is high (either high client → server network latency or simply the server response latency being high, aka high server load).

If so, can we start with implementing this while accepting that not every prop's resolved value (see: EvaluatedComponentModel

My concrete proposal:

1. for many prop shapes, we already have client-side transforms for the used field widget
2. we have JSON Schema information for each such prop, which allows client-side validation of the resolved value against the JSON Schema
3. restrict scope of this issue to only those prop shapes where #1 (a client-side transforms) exists, and which meets #2 (transforms to a valid resolved value per the JSON Schema for that prop)
4. leave EVERYTHING ELSE to follow-up issues: A) client-side transform exists but does not pass client-side JSON Schema validation, B) client-side transform does not yet exist but is possible, C) client-side transform to resolved value is impossible (for example: media library widget), but we could do some client-side caching — A+B+C can then be follow-ups that improve the state this issue would put us in.

That way, we can start implementation any time (even today), and learn what the most valuable missing pieces would be.

restrict scope of this issue to only those prop shapes where #1 (a client-side transforms) exists, and which meets #2 (transforms to a valid resolved value per the JSON Schema for that prop)

Where can I find a list of prop types that meet this criteria?

Postponing this on ✨ Unwrap astro-islands and astro-slots Active , because that issue will make this one more complicated, because once we remove the astro wrappers, it's less clear how to then target the component instance and re-render it with updated props. It's definitely solvable, just trickier.

Related, it doesn't strictly need to block a beta despite #5. Though I still stand by #5 as a strong nice-to-have, so instead of removing the "beta blocker" tag entirely, this is now our first issue that I'm tagging as a "beta target". And now that we have our first one, we'll likely start using this tag for some other issues as well :)