/
2025-09-11 Frontend Working Group Meeting Notes: Consequences of Frontend-base Summit Decisions

2025-09-11 Frontend Working Group Meeting Notes: Consequences of Frontend-base Summit Decisions

 Date, time, location

 Discussion topic(s)

One, maybe two topics to be presented or discussed in depth in the upcoming meeting.

🎥Recording

 Participants

Adolfo Brandes, Brian Smith, Diana Villalvazo Salas, Jesse Stewart (WGU), Max Frank

🤖 Summary

A summary of the meeting, generated from the transcript by an LLM and reviewed by a human.

TL;DR

  • React Query over Redux is preferred going forward—convert when feasible, but don’t block existing Redux cleanup PRs.

  • Frontend Base (FB) migration proceeds with operator opt-in per MFE and a period with two maintained branches (legacy vs FB).

  • New features should land on FB first whenever possible; legacy gets fixes and only select improvements.

  • Pause starting new MFE conversions until gaps/missing features are addressed and aligned with maintainers/community.

Objectives

  • Recap decisions on Frontend Base and set near-term do’s/don’ts.

  • Clarify Redux → React Query strategy.

  • Align on branch strategy, release testing, and deprecation approach.

Key Decisions & Guidance

  1. Redux → React Query

    • Preferred path: Move MFEs to React Query to avoid unnecessary refetches caused by Redux providers being reinstantiated under FB’s shell/MFE lifecycle.

    • Practical stance:

      • Don’t block existing Redux cleanup PRs; land them if they help readability or pave the way for Query.

      • When choosing between “cleanup Redux” vs “migrate to React Query,” migration is preferred if bandwidth allows—acknowledging it’s a non-trivial effort.

  2. Operator Toggle & Deployments

    • Operators should be able to toggle FB per MFE for at least one and at most two releases.

    • This implies two versions (legacy vs FB) exist for a while; routing implications (React Router behavior across mixed MFEs) need design work.

  3. Branching Model

    • Expect two branches per MFE for a time (legacy + FB).

    • Maintainer’s choice whether to frequently merge master → FB or let them diverge; recommend merging only when it’s low-friction (bugfixes/small changes).

  4. Where new work lands

    • Default to FB for new feature development (developer/maintenance efficiency).

    • Legacy may still receive bug fixes and some improvements when product/operator impact warrants it (case-by-case).

  5. Pace & Scope

    • Do not start converting new MFEs until missing FB features and key gaps are addressed and the community is consulted.

    • Newly created MFEs targeting upcoming releases should start on FB (e.g., Instructor Dashboard already doing this).

  6. Testing & Releases

    • During releases, expect to run two sandboxes (legacy and FB) to validate both tracks.

  7. Library Upgrades

    • Prefer doing cross-cutting upgrades (e.g., React Query adoption, Router 5→6) in master first when safe, to benefit everyone; large/ risky changes may be FB-only.

  8. Deprecations (e.g., Hotjar, NoticesWrapper)

    • No mass deprecations in master as a prep step; the toggle gives operators time.

    • It’s fine to run individual DEPRs (forum + Slack notice, reasonable window) for clearly scoped removals (e.g., Hotjar in Learner Dashboard) if stakeholders agree.

Open Questions / Risks

  • Mechanism for per-MFE toggle (builds, images, and Tutor/Caddy routing strategy) remains to be designed.

  • Routing across mixed legacy/FB deployments without full-page refreshes needs exploration.

  • Workload of dual maintenance for ~18 months (rough, based on “Verawood + 1”)—mitigation via clear “what lands where” rules and documentation.

Action Items

  • Adolfo:

    • Draft proposal for per-MFE deployment toggle (technical mechanism).

    • Document FB wins for operators/users to aid adoption and product alignment.

  • Diana: Continue Instructor Dashboard on FB with React Query; prefer migration over deep Redux cleanup when effort is comparable.

  • Brian: Outline/coordinate community comms so external projects plan new front-end work on FB first.

  • Max: Start DEPRs for Hotjar and NoticesWrapper in Learner Dashboard (forum + Slack; gather consent from known users).

  • All maintainers: Before converting an MF, sync with the MFE maintainer on branch policy (merge vs diverge) and any feature freeze expectations.