arbrandes
October 5, 2023, 4:43pm
9
First off, these are all good points, @ghassan , but they’re only tangentially about pluggability, so I’m not sure they have a place at the summit.
Here are my hot takes, though. Back to front:
ghassan:
Xblock/Units to utilzie Paragon/React
There’s already a detailed issue written up for this:
opened 07:34PM - 25 Apr 23 UTC
epic
## Goal
Full completion would mean:
* Give XBlock developers access to the… same modern frontend framework (React) and accessible component library (Paragon) that micro-frontend developers use.
* Support all views: student, public, author, and studio.
* Equally support all blocks, including the ones in edx-platform (eg, problem) and the ones in other repositories (eg, lti_consumer). This means that the new React views cannot be baked into core repositories.
* Retain parallel support for existing edx-platform-rendered XBlock frontends.
* Avoid regressions in performance, accessibility, i18n, or security.
Non-goals:
* A new JS-based courseware plugin system separate from XBlock. This is an interesting idea, and has explored in the ["NeXBlock" writeup](https://docs.google.com/document/d/1btnE7pIZccvlrDrJ8gHjEPfOrkMCZgSkgw8D9jXaLx4/edit#heading=h.90apnqnmcp86). For this epic, though, we're interested in evolving the existing XBlock ecosystem.
* Supporting blocks above the unit level, eg sequence. The [established direction of edx-platform](https://github.com/openedx/edx-platform/blob/master/docs/decisions/0006-role-of-xblock.rst#decision) is that XBlocks should be used to customize courseware within the unit, but customizations to course structure should be left to separate, declarative systems.
## Prior Work
### Enhanced editors for Text, Video, and Problem
https://github.com/openedx/frontend-lib-content-components/blob/main/docs/decisions/0003-V2-Content-Editors.rst
### Hackathon: React HTML block student view
### Hackathon: React HTML block student view
We (@nsprenkle & @muselesscreator) worked on a proof of concept during a hackaton project. **Note** that the actual APIs we are calling are probably not the way we want to do this and we also dangerously set inner HTML of a block on the page, but the valuable bit here is we played with having multiple types of render logic from the Learning MFE,
Source: https://github.com/openedx/frontend-app-learning/tree/bw/hackathon
The **TL;DR** of how we think this should work:
1. Add frontend components for (or all) of the native `edx-platform` XBlocks to the Learning MFE. Others could be installed the way we install other frontend components (e.g. Header / Footer)
2. Create a list of frontend-renderable XBlocks supported by the Learning MFE (we've been calling these FRend blocks).
3. Update the XBlock backend with an endpoint for returning JSON data, instead of HTML using the `xblock.json_handler` functionality. An option is to use the `student_view_data` paradigm used in some other environments (e.g. mobile app).
4. When the Learning MFE looks at a unit, it identifies if some/all of the content is frontend-renderable (FRendly).
5. **Up for debate** on the best rendering scheme, whether we only drop to frontend rendering only when all blocks are FRendly, or a majority, or while under some threshold for un-FRendly blocks on a page.
7. For each FRend XBlock on the page (or with some other bulk retrieval scheme), call the data endpoints on those XBlocks for the data to render those blocks, render at the block level.
8. For remaining un-FRendly blocks, create `iframes` to render the individual/grouped blocks HTML.
**Note** that this should also probably be configurable per-course as some hacky (but desired by course staff) behavior could be lost with this new pattern.
#### Other things we learned
1. A similar pattern was investigated during the development of the Learning MFE, but was dropped because it was considered too challenging to implement all supported XBlock frontends. This option is more iterative and allows us to continue `iframe`ing old-style HTML XBlocks while we implement frontends for the more common components.
2. The `iframe` sandbox is both a blessing and a curse. This adds security and separation from the course material and our course chrome but doesn't give us access to that course content from the Learning MFE, blocking features like context-aware annotations.
3. There is an `iframe` performance overhead that gets progressively worse for multiple `iframe`s on a page. Suggestion was to think of a rendering scheme that defers to old style unit rendering if there would be too many iframes rendered to the page.
4. Course staff have lots of *interesting* hacks and tweaks to XBlocks including custom JS that cross communicate between blocks. I argue this is a bad idea, but staff seem to like it and it is a competitive differentiation. Suggestion was to allow opt in/out for a course / org.
## Considerations & Open Questions
* Where do the React frontends live?
* As an NPM package in the same repository as the XBlock backend?
* How would the MFEs (learning, course-authoring, library-authoring)...
* discover & install the correct NPM packages for all installed XBlocks types?
* discover & load the correct JS modules with the frontend React components?
* How do we handle units with a mix of legacy and React-enabled blocks?
* Fall back to legacy views?
* Group legacy blocks into views, something like this?
```
<Unit>
<iframe>
<legacy-block ... />
<legacy-block ... />
</iframe>
<ReactEnabledBlock/>
<iframe>
<legacy-block ... />
<legacy-block ... />
</iframe>
<ReactEnabledBlock/>
</Unit>
```
* Currently, XBlocks in the same unit can "talk" to one another with JS. Would React-enabled blocks support that? If not, is it OK to break that?
* Security: Currently, the unit iframe sandboxes instructor-authored XBlock content to a certain extent, protecting site from courseware script injection. How do we retain that security when rendering React-enabled blocks directly into the Learning MFE?
* Should we worry about drift between legacy frontends and React frontends?
* Would we ever deprecate legacy block frontends?
* This whole proposal assumes React as a framework. Should we avoid that assumption?
## Tasks
```[tasklist]
### Tasks
- [ ] https://github.com/openedx/XBlock/issues/634
```
ghassan:
Merge FE repos togathers
Mono-repos have pros and cons. The biggest con right now is that we don’t have a lot of experience with them, and it would require a bunch of retooling. In other words, there should be significant discovery into what exactly we would be gaining.
@AdamStankiewicz may have some insight, as, reportedly, Enterprise has started some experimentation in that direction.
ghassan:
Create a mock service/server for Open edX frontend Dev
I think that without dev data (OEP-37), it becomes really hard to build a mock service that’s actually useful.
But, in any case, there have been related conversations around Pact, recently. @DawoudSheraz gave a presentation on it on June 1 to the Frontend Working Group. I think this is a good thread to follow, going forward. But, again, not in the Pluggability summit.
1 Like