2024-08-29 Frontend Working Group Meeting Notes: Plugin Prop Customization

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

 Date, time, location

 Discussion topic(s)

  • Vendor-specific prop customization (@Adam Stankiewicz)

  • Module federation update (@David Joy)

🎥Recording

 Participants

Adam Stankiewicz, Adolfo Brandes, Brian Smith, David Joy, Fox Piacenti, Hina Khadim, Jason Wesson, Juan Carlos Iasenza, Leonel Katsikaris, Max Frank

🤖 Summary

  1. Custom Props for MFE Components (Adam Stankiewicz):

    • Problem: Currently, specific props (like Hot Jar suppression) are hardcoded across the platform, which is not open-source-friendly. There is no standard way to merge props with existing components.

    • Proposed Solution: Extend the Frontend Plugin Framework (FPF) to allow merging custom props with default components. The new approach includes a slotOptions prop, enabling prop merging without affecting existing users.

    • Challenges:

      • Prop merging assumes single-element children in plugin slots, which may need refinement.

      • The debate on whether plugin slots should wrap certain elements (e.g., usernames) or directly modify their props was discussed.

      • The complexity of handling multiple plugin slots and instances in MFEs, and how to avoid wrapping elements with different CSS styles (e.g., div vs. span).

  2. Module Federation and Future MFE Architectures (David Joy):

    • Module Federation Overview:

      • MFEs can now be deployed in two main ways: as part of a unified build or using module federation, which loads components dynamically from different locations at runtime.

      • Challenges: Different organizations have varying needs—some prefer modular micro frontends (MFEs), while others favor a unified site with shared dependencies.

    • Vision: The future architecture allows flexible ways to build and deploy MFEs, balancing operator simplicity and developer flexibility.

    • Key Features of Future MFE Architecture:

      • Site Config vs. Module Config: Operators can use a single site configuration to control all modules, reducing complexity. Each MFE can be federated as a module and loaded dynamically.

      • Customization: Operators can either rely on pre-packaged apps or customize them within projects. This architecture also allows lazy loading of specific MFE components.

      • Separation of Concerns: Long-term, plugin authors would manage the complexity of prop spreading and configurations, minimizing the burden on operators.

  3. General Discussion:

    • Complexity of Plugins and Slots: Adolfo and others suggested simplifying the plugin configuration process, especially for operators who need to add minimal customizations, like hot jar suppression.

    • Developer vs. Operator Responsibility: There’s a clear distinction being made between the expectations of developers (plugin authors) and operators. The goal is to keep the operator-facing complexity low.

    • Future Steps: Several ADRs (Architectural Decision Records) are forthcoming, and it’s a good time for stakeholders to provide input before finalizing changes.

Next Steps:

  • Further refinement of the proposed plugin approach, ensuring the architecture simplifies operations while maintaining flexibility for developers.

  • Reviews and feedback on upcoming ADRs to ensure alignment with community needs.

The meeting concluded with plans to continue refining these ideas, and further involvement from developers and stakeholders is encouraged.

 Action items

 Decisions