...
The summit was called to address issues with XBlock rendering, particularly focusing on performance problems encountered when rendering unit pages with many XBlocks. This has led to a poor user experience in Studio, prompting the need for a better solution.
“Single Iframe Solution” Proposal by Dave Ormsbee
...
(Axim)
Instead of rendering each XBlock in its own iframe, use a single iframe for all XBlocks and manage their placement and interaction via post messages.Advantages: This would simplify the rendering process, improve in a Unit using the
/xblockendpoint of the preview server.Have that unit rendering include empty divs as placeholders.
Have the Authoring MFE overlay the per-Component toolbars on top of those placeholders.
The iframe contents use
postMessage()to communicate the locations where those overlays are needed, in a way that is similar to what happens with iframe re-sizing on the Learning MFE.
This is a more tactical proposal to move Studio to the new Unit page, and does not conflict with other, larger scale, long-term modernization efforts.
Advantages:
Improves performance by reducing the number of iframes and significantly reducing the number of JS assets that need to be processed.
Does not require major rewrites of XBlock or runtime functionality–seems feasible to do for the Sumac timeframe.
In the longer term,
may provide us with better fidelity previews that are inline with the Unit itself (and give us a way to move off of needing a separate preview domain).
In the longer term, may give us an acceptable pattern for frontend plugins to decorate and interact with XBlock content (e.g. “submission history”, “staff debug”).
Challenges:
Not a common pattern, which may lead to confusion.
Re-ordering components in a unit will likely require some special case handling (e.g. hiding the iframe and collapsing the component toolbars together), because we can’t reorder within the iframe document.
Proposal by Braden MacDonald
...