2023-02-16 Frontend Working Group Meeting Minutes

 Date

Feb 16, 2023

 Participants

TBD

Recordings

 Discussion topics

Time

Item

Presenter

Notes

Time

Item

Presenter

Notes

20 minutes

Loading external themes

 

@Adam Stankiewicz's

tl;dr;

  • Paragon’s design tokens intends to compile its own theme CSS instead of MFEs needing to compile Paragon’s SCSS → CSS.

    • It would result in core.css and light.css CSS files.

    • See for more details.

  • Relies on 2 new config variables being present (potentially 3+ in the future):

    • APP_THEME_CORE_URL (core theme CSS)

    • APP_THEME_LIGHT_URL (CSS variable definitions specific to light theme variant)

    • [in the future] APP_THEME_DARK_URL (CSS variables definitions specific to dark theme variant, one day)

  • Implements useAppTheme React hook to load/inject the external theme URLs into the HTML <head>.

  • Does not render MFE until the external CSS is loaded to avoid Flash of Unstyled Content (FoUC).

  • Ensures that once we do support more than 1 theme variant (i.e., both light and dark), switching between them does not introduce FoUC.

  • Provides a mechanism for consuming MFEs to (eventually) switch the theme at runtime by exposing a dispatch function and a set of reducer actions to mutate the app theme state (e.g., a consuming MFE could do dispatch(setAppThemeVariant('dark')) in the future once more theme variant(s) beyond "light" is supported.

Discuss:

  • What about versioning?

    • For example, will the externally hosted CSS (e.g., on CDN) ever be incompatible with the version of Paragon installed in each individual MFE?

      • Should the externally hosted CSS be versioned in some way?

    • Concerns around using an open source, versioned CDN that’s always in sync with published NPM versions?

  • Local development?

    • Currently, I have a Node.js Express API running locally with endpoints to serve the compiled core CSS and the light theme variant CSS from my local Paragon checkout.

    • Need to explore options if there’s a way to point the config variables to CSS files from local checkout of Paragon without needing to serve them from a running Node.js Express API.

  • Alternatives to hosting compiled CSS on a CDN in our current MFE architecture?

    • Brian Smith suggested possibly looking into (S3-like object storage for Open edX) as possible alternative.

      •  

 

Update on MFE Domains

@Pedro Martello

  • Feature comparison between Piral and single-spa

    • Piral is more opinionated.

      • Everything’s thought out; implementation for addressing most concerns (e.g., routing from domain MFE to child MFEs, events, state sharing, etc.).

      • Implementation route is a bit simpler here.

      • Extensions

      • Sharing dependencies:

    • single-spa is less opinionated.

      • Solves a narrower piece of the pie; notably the routing between views.

      • Supporting libraries to aid in extending single-spa.

        • “You make a lot of decisions on top of the framework”

  • The other suggested alternatives thus far are “roll-your-own”.

  •  

7min

 

Ghassan


I can present the diff of css between with and without the purge css plugin

git diff --no-index dist/app.4fce923d8a1007f74bd7.css dist-with/app.2abb1105ce90dd2f22da.css

 Action items

 Decisions