Content Libraries Post-Sumac Arch/Dev Priorities
Let’s collect some high-level themes for arch/infrastructure work that we should consider for Teak and after.
These are things that wouldn’t necessarily come up from the product viewpoint. So there’s no need to put things like, “Make video subtitles work properly”. These are also meant to be fairly broad topics, with the idea that we’ll groom them into more actionable stories later.
Goals
Make sure we’re not just completely forgetting about a major refactoring because we’re so busy hitting immediate deadlines.
Get an early start on some of these initiatives if possible.
Make sure we have these things in mind as we’re building new features like Units, so that we can interleave some of that work in an intelligent way.
React Query
Should we be planning to move from Redux -> React Query?
How disruptive would this be, and what timeline could we achieve it on?
Would this make our frontend less chatty (we throw a lot of requests around)
Removing XBlock-orientation
We use “blocks” in the API a lot, but some things should be generically applicable to components (e.g. file upload, tagging), some are applicable to any publishable thing (e.g. “publish”), and some are specific to XBlocks.
XBlock Compilation Step?
We currently parse block.xml
for our field data parsing, but in the past we’ve talked about having a compilation step so that we could do things like:
pre-render math into MathML on the server side
store Python source files next to the
block.xml
and compile them in.store HTML data in an HTML file, rather than in CDATA
The goal would be to give better authoring flexibility while making sure that any content data that an XBlock needs is entirely contained within one row of a model that is 1:1 with ComponentVersion
. This might only work well once we have courses switched over to use Learning Core.
Extensibility
We should work as much of our own code into Slots and other extension points–at least as much as is practical.
I think Sumac is our “sure, kick the tires, but don’t actually extend this” release, and we should target Teak for our first actually usable extension points for enhancing the content libraries experience.
Dev Documentation
Learning Core needs doc generation.
Likewise with Libraries in general.
Tracking Usages
We need a new place in the database to track usages, to power two things:
In libraries, show where a given library component is used (downstreams list)
In a course, or even in Studio as a whole, show all the downstream usages that have an update pending (newly published upstreams)
Import/Export
We want a smart format for library import/export. Lots to consider here.
XBlock Runtime & Rendering
Can we simplify it?
Support all XBlock types in content libraries, not just the ones with MFE editors.
Move from the Legacy Unit page to MFE Unit page, including all “source from library” UI
Migration off of legacy libraries
Migrate V1 libraries to V2 libraries
Migrate LegacyLibraryContentBlocks to work with V2 libraries
Remove “V1 sync” code
Prepare to migrate courses to Learning Core
Cross-Instance References
Architecturally, we’re still in a place where I think we can support this without too much difficulty. How worthwhile is it to explore this in the Teak timeline?
Example minimal implementation: key generated on a per-library basis, stored in the course data.