2025-03-26 Meeting notes

ModalDialog 's isOverflowVisible prop defaults to true on v22

@Adam Stankiewicz

https://github.com/openedx/paragon/issues/2938

Context:

• PR was merged to add isOverflowVisible prop, with default fallback to true.

  • This was done to fix https://github.com/openedx/paragon/issues/2938

  • Released in v22.1.0.

• An issue was reported around modal bug issues that results in style issues due to the default to true.

• Since then, isOverflowVisible was migrated to a required prop instead. But only in v23.

• However, this still risks leaving several broken modals on v22 (e.g., with lengthy content and/or users collapse their window height).

• [questions]

  • Should we at least be calling out the likelihood of consumers needing to pass isOverflowVisible on the v22 docs site?

    • The truthy default is breaking in v22, so without any explicit mention in the docs, consumers won’t know they have to provide it for their overflowed modal content to work correctly.

  • To mitigate potentially unresolved regressions that we don’t know about explicitly, should we change the default to false and explicitly opt-in to the isOverflowVisible on only the components that actually need it versus impacting all components that may or may not need it (with possible unknown, existing regressions).

Notes:

• In v22, we will change the default from true to false OR make the prop required.

  • Technically, but released as minor.

  • Be very explicit in release notes about the rationale.

• Is it possible to have consumers NOT need

  • It seemed like it needed to be

edx/frontend-lib-learning-assistant

@Adam Stankiewicz

https://github.com/edx/frontend-lib-learning-assistant/pull/91

Summary:

• frontend-lib-learning-assistant is a library supporting the 2U/edX Xpert AI feature.

• It’s directly installed/consumed within openedx/frontend-app-learning.

• The library imports Paragon’s styles via src/index.scss.

  • Concerns:

    • Re-importing likely results in unnecessary duplicate Paragon styles for the MFE.

    • The styles path for @openedx/paragon and @edx/brand have changed to support Paragon v23 in this file, meaning the change must be released as breaking (new major version).

• Questions

  • Does this library actually need src/index.scss to re-import all of @openedx/paragon and @edx/brand?

  • If not, can this file be deleted?

Notes:

• Iff we release as breaking, we want to merge React 18 support (non-breaking) before.

Paragon v23 RTL support

@Adam Stankiewicz

https://github.com/openedx/paragon/pull/3496#issuecomment-2751230432

Should Paragon's compiled CSS include postcss-rtl like @openedx/frontend-build so that when Paragon's styles are imported from an external CDN URL as shown above, its styles properly handle RTL out-of-the-box?

See @openedx/frontend-build’s usage of psotcss-rtlcss here.

Next steps:

• Understand scope of problem further by testing various Paragon components with RTL style properties with and see what breaks.

• Test side-by-side between Webpack (frontend-build) + Paragon styles (external CDN).

• Potential resolution

  • Understand diffs between Webpack vs. external Paragon.

  • Add postcss-rtlcss to Paragon v23 styles and re-test.

  • @Adam Stankiewicz file a github issue to track.

Duplicate copies of Paragon in several MFEs

@Adam Stankiewicz

Example: https://github.com/openedx/frontend-app-learner-dashboard/issues/325

Known culprits (there may be more):

• frontend-app-learner-dashboard

• frontend-app-ora-grading

• …

Next steps:

• @Brian Smith to make public engineering issue for this

Notes:

• Pre-design tokens, these stylesheets should be imported in the MFE’s styles entry point to avoid re-importing Paragon multiple times.

• With design tokens, these stylesheets could use Paragon’s CSS vars without needing to import anything.

Paragon docs site stylesheets

@Adam Stankiewicz

• It appears the Paragon docs site on v23+ still imports the SCSS core vs. the CSS core, despite importing the CSS themes.

  • https://github.com/openedx/paragon/blob/4d8d02e3a191b5fda2cc879216e150c36ceb8c9a/www/src/scss/openedx-theme.scss#L1

• Shouldn’t the docs site only be importing the pre-compiled CSS, not the SCSS, at this point?

Design tokens and openedx named releases

@Brian Smith

• Release schedule Open edX Release Schedule

• Cutting teak.master MFE branches from master-design-tokens branches of MFEs is not desired.

  • This means for design tokens to get into teak every org that deploys from master would need to be ready before Apr 9, 2025

• The other option is to have ulmo be the first named release to support design tokens.

  • This means continuing to support Paragon 22 for longer (just bugfixes once teak is cut, but would need to address those though the end of the year).

Notes:

• April 9, 2025 is a bit too early for 2U/edX.org, though v23 support is actively WIP.

• Other instances (e.g., MIT) have not started yet.

• Decision: we will continue to support Paragon v22 throughout teak (any non-breaking contributions still allowed, but will be primarily bug fixes).

  • We need to set a date for when the master-design-tokens branches cut to master.

  • Discourse forum post by @Brian Smith to folks who deploy from master.

    • Align on what date is viable/feasible for folks in this group.