Content Libraries Post-Sumac Arch/Dev Priorities

Owned by Dave Ormsbee (Axim)
Last updated: yesterday at 4:31 am
3 min read

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

  1. Make sure we’re not just completely forgetting about a major refactoring because we’re so busy hitting immediate deadlines.

  2. Get an early start on some of these initiatives if possible.

  3. 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.

Course content Migration Strategy