2025-09-25 Frontend Working Group Meeting Notes: react-query key structure, frontend-base next steps
Date, time, location
Date:Sep 25, 2025 at 15:00 UTC (timezone converter)
Location: https://meet.google.com/wxe-myxy-uei
Discussion topic(s)
React-query queryKey factories and structure
Frontend-base next steps:
Reviewing/merging Gradebook, Account, Profile, and Discussions initial conversions (@Adolfo Brandes , Jacobo, Javier)
Keeping tabs on frontend-app-instruct progress (@Diana Villalvazo)
Is react-query required, or just nice to have? (Javier)
Design tokens (@Adolfo Brandes and @Brian Smith)
Rebase of existing conversions on master, after Design Tokens support lands. Includes getting all tests to work. (@Adolfo Brandes, Jacobo, Javier)
Lazy loading (@Adolfo Brandes)
tutor-mfe support (@Adolfo Brandes)
rsbuild vs vite discovery (looking for volunteers)
🎥Recording
Video:
Frontend Working Group Meeting - 2025/09/25 10:56 EDT - Recording Chat:
Frontend Working Group Meeting - 2025/09/25 10:56 EDT - Chat Transcript:
Frontend Working Group Meeting - 2025/09/25 10:56 EDT - Transcript
Participants
Adolfo Brandes, Brian Smith, Diana Villalvazo Salas, Jacobo Dominguez
🤖 Summary
1. Query Key Factory Proposal
Context: Adolfo proposed improvements to how React Query keys are managed in the admin console MFE.
Key Points:
Suggested using query key factories instead of hard-coded strings.
Recommended structuring keys from most generic to most specific, starting with the app ID (e.g.,
oropanetics.frontend.app.learner.dashboard).Helps prevent conflicts across MFEs, improves debugging clarity, and ensures cache consistency.
Discussion:
Brian and Diana supported the idea.
Concern raised about app ID uniqueness if multiple developers use generic names (e.g., “checkout”).
Solution: use reverse DNS naming (e.g.,
com.opencraft.checkout) to enforce uniqueness.Adolfo suggested documenting this pattern later as an ADR, but starting with an implementation first.
2. Updates on MFE conversion
Current Work:
Jacobo and Javier are progressing on their MFEs.
Profile MFE: Jacobo took it over after Victor dropped out.
Gradebook and Account MFEs: PRs under review; Javier expects to push updates this week.
Timeline:
Several MFEs (including Dashboard) expected to be available experimentally for OMO in October.
Tight deadlines due to the upcoming Ulmo cut (October/November).
3. Design Tokens & Paragon Integration
Adolfo’s Work: Attempted to port commits from
frontend-platformandfrontend-buildto frontend base.Decisions:
Base Paragon styles don’t need to be loaded separately; only overrides will be managed.
This simplifies implementation while keeping consistency across MFEs.
Tooling:
Use the Paragon CLI (
replace-variablescommand) to update CSS variables.Goal: enable design token support across MFEs.
Next Steps:
Adolfo will draft a PR for frontend base and one converted MFE.
Brian to review and test with example themes.
Target completion: by next Thursday (Sept. 30) for initial implementation.
4. Build System Discussion (RSBuild vs Vite)
Comparison:
RSBuild: faster but less mature.
Vite: fast, widely adopted, more community support.
Consensus:
Favor Vite for long-term maintainability.
Need to verify compatibility with MConfig.jsx and plugin loading.
Adolfo and Brian agreed more evaluation is needed before committing.
5. Tutor Plugin & Frontend Base Strategy
Proposal:
Create a separate Tutor MFE plugin for frontend base instead of overloading the existing Tutor MFE.
Pattern would mirror the Paragon plugin: bundles hosted as extra static files via Caddy.
Benefits:
Cleaner separation.
Easier configuration via Django settings.
Supports flipping between MFEs without heavy rebuilds.
Closing Notes
Meeting ended on a positive note, with consensus on several technical strategies.
Emphasis on tight timelines (Ulmo release by late October/November).
Team agreed on a clear path forward for query keys, Paragon integration, and frontend base plugin structure.