Context

Recently, at an Arch Tea Time and at a Consumer Review, questions were raised on tradeoffs and decisions on when to rewrite legacy frontend pages to MFE technology.

Recommendation

The following set of recommendations can be used as a basis for discussion by the owning squad. As with other implementation decisions, consider tradeoffs between schedule, budget, and resources, along with code quality as defined below.

New large-scale frontend development

Implement new large-scale frontend development using our latest frontend technology: React-based micro-frontends, bootstrapped with our frontend-template “cookie-cutter”.

Updates to legacy frontend code

'Minimal' changes

For a minimal required change, the team will likely not invest in an entire re-write effort.

‘Medium effort’ changes

For a more substantial change, here are a few options that the owning squad can consider given other business considerations.

• Option 1 Rewrite: Invest in a complete rewrite if this is a “core” functionality of the platform and the business expects to innovate further in this area.

  • Note that this rewrite could be resourced via a blended project.

• Option 2 Stepping Transition: A middle-ground approach is to use ReactRenderer to embed new React code into legacy code. Implementing the newer code in the latest supported technology is a good transitory stepping stone in anticipation of a future rewrite.

  • The new React code can be implemented as its own separated “nano-FE” code that is included into the legacy FE code.

• Option 3 Stick with Legacy: The team can decide to simply stick with the legacy frontend code for now, especially if the required change is in a part of the frontend experience that

  1. is expected to be deleted (see DEPR board).

  2. is scheduled to be rewritten within the next year (see https://openedx.atlassian.net/wiki/spaces/FEDX/pages/1920270629).

  3. is not critical to business operations and not expected to be updated with feature changes in the next 2 years.

Quality

• For MFE rewrites, see https://openedx.atlassian.net/wiki/spaces/FEDX/pages/1917944547.

• For legacy frontend updates that are somewhat temporary (e.g., #1 and #2 in Option 3 above), the team may choose to not invest as much time on otherwise “Clean Code” practices - with the caveat that the team create a backlog reminder to remove any “hack” code within (3) months. Adding a TODO statement in the code along with a link to a Jira ticket is one way of tracking this.

Sub-Pages