Arch Hour: 2020-10-01 (Learning MFE Q&A)

For this Arch Hour, we’ll have a Q&A session with the TNL Squad. TNL will answer questions regarding the new Learning Microfrontend, including Why, What, How, Future thoughts, etc.

Video: Zoom recording

Why rewrite the Courseware frontend?

  • Same as other frontends, to increase developer velocity.

    • Have been working up to this one for a while. Courseware and innovation in courseware is essential.

      • Easier pluggability

    • Enable experimentation of frontend changes.

  • Isolation boundaries

    • Course team authored JS

What part of the Courseware was including in this rewrite?

  • Is the iframe staying? (Unit)

    • Yes

  • What’s in the iframe?

    • Unit (everything below the sequence nav and Unit title)

  • Is this iframe true for course discussions/inline discussions module too?

    • Yes, for now. Eventually inline discussions would become an example of a plugin in an in-context sidebar.

  • How do we avoid iframe scrollbars-in-scrollbars?

    • iframe-> parent messaging to report size so parent can resize (we control both sides)

  • Why iframe?

    • Isolation

    • Insulate us from the complexity of what the XBlock runtime does to render units

  • What happens when you click the back button?

    • Does the right thing, react-router

How was this process of development/rollout/etc? any learnings?

  • React Hooks

  • Class-based components instead of Function-based components

  • Adding a feature to legacy vs new MFE

    • so much easier in the MFE

  • Rollout: New Relic dashboards were helpful

  • Waffle system is powerful and complicated

  • Tail-end - content issues vs code issues


  • With MFE+ (LMS) iframe; How does it change the game for someone reading course engagement analytics? or it does not?

    • For someone using Insights, shouldn’t impact anything.

    • Some blocks like ORA have inline reports, and those will still work in the iframe.

  • When translating features over to the MFE from the LMS experience, were you expecting parity with the old UI? Or were there iterations with the design team to improve the UI, and at what point of the process did you interact with them? (I realize there isn’t too much happening outside of the iframe… tabs, breadcrumbs, previous/next sequence buttons)

    • Baseline for most of our MFEs has been to achieve parity, and then to do some safe, opportunistic changes (e.g. responsive improvements)

    • Design team was pretty small at the beginning of the project, didn’t have much bandwidth.

  • Were there any significant learnings that came out of the rewrite?

    • Heavily used React hooks in this, learned a lot about when to use these, class vs. functional, etc.

      • Steven: More of a lean towards class based

    • Before we went live, was able to add a feature to both the legacy and the new MFE and the experience was much better in the new MFE

    • Appreciation for good New Relic charts, dashboards.

    • Understanding that our waffle system is more complicated than we thought, but it’s also really powerful.

    • Separation of XBlock course content from navigation and other high level systems necessary to fix performance issues.

    • Better messaging, because it was a lot of infrastructure work and not very visible

    • Tail end of MFE rewrites can be really long, to reach feature parity, etc. Need a dedicated team to swarm.

    • Content issues vs. code issues.

    • Other teams were really waiting for this MFE to be ready to go so they could make changes.

      • Now what? What can we do to better enable other teams?

    • We made it available to course teams but didn’t measure whether they actually do so.

  • Which top level tabs are going to be part of the MFE?

    • engage-squad is doing a lot here, rebuilding progress, course home, dates, celebratory milestones

    • discussions will become a new MFE