2024-09-12 Frontend Working Group Meeting Notes: React Data Router and Prop Merging

Owned by Adolfo Brandes
Last updated: Sept 26, 2024
2 min read

 Date, time, location

 Discussion topic(s)

React Data Router, prop merging with FPF

🎥Recording

 Participants

Adolfo Brandes, Brayan Cerón, Brian Smith, David Joy, Fox Piacenti, Juan Carlos Iasenza, Leonel Katsikaris, Milad Emami, Mohamed Rafeeh Ibrahim, Rabeeh T A

🤖 Summary

  1. React Router Update (David Joy):

    • React Data Router: The enterprise MFEs (Micro Front Ends) are using React Data Router, a more mature and opinionated version of React Router that separates component rendering from route loading, which allows for better data handling.

    • Impact on MFEs: Migrating to the new React Data Router could be straightforward for simple MFEs but more complex for deeply nested applications like the course learning MFE, which has specific routing and loading logic.

    • Refactor Scope: The switch to React Data Router would be a larger refactor compared to moving between previous versions of React Router, potentially leading to rewriting parts of the MFEs if combined with tools like React Query.

    • Decision Point: The group discussed whether it’s worth doing other updates (like React Query) alongside the router update or keeping the scope focused on the routing refactor.

  2. Module Federation and MFEs (David Joy):

    • David shared his progress on Module Federation and integrating React Data Router into the frontend base and MFEs. The setup allows lazy loading of modules, with headers and footers being switched dynamically, but the group agreed that a commitment to using React Data Router may be needed for this system to work efficiently.

  3. Customization API and Plugin Framework:

    • Customization Needs: The group discussed the ongoing work around customizing the MFEs using the frontend plugin framework (FPF), particularly for modifying props (e.g., replacing a logo’s URL).

    • Flexibility vs. Complexity: David raised concerns that using the plugin framework to manage simple changes like modifying a URL could introduce unnecessary complexity. He suggested that a configuration-based approach might be simpler for such cases. Adolfo agreed, highlighting that they are in an "in-between" phase, moving away from environment variables for each change toward a more generic customization API.

    • Merging Props: Brian mentioned that Adam’s recent work on merging props within the plugin framework had landed successfully and is being used in the header slot PR, allowing more flexible modifications without replacing entire components.

  4. Open Topics and Ongoing Work:

    • PR Reviews: Adolfo encouraged attendees to bring up any PRs or issues needing attention before the upcoming master cutoff (for the Sumac release), which would complicate backporting changes.

    • Frontend Header Work: Brian gave an update on his work on the header component, mentioning that it uses the newly implemented prop merging capabilities.

    • API Usability: Adolfo reiterated the need for the API to remain user-friendly and sane, balancing the flexibility of the plugin framework with avoiding unnecessary complexity.

  5. Next Steps:

    • Adolfo will focus on reviewing the plugin slots and working on module federation with David.

    • David is working on unifying front-end code across repositories and converting it to TypeScript, which will require several PRs for review.

The meeting concluded with a reminder for developers to get involved in discussions about the customization API and other ongoing work.

 Action items

 Decisions