-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BD-46] feat: added support Paragon design tokens #351
base: master
Are you sure you want to change the base?
[BD-46] feat: added support Paragon design tokens #351
Conversation
Thanks for the pull request, @PKulkoRaccoonGang! This is currently a draft pull request. When it is ready for our review and all tests are green, click "Ready for Review", or remove "WIP" from the title, as appropriate. |
80f93ec
to
17aee00
Compare
example/index.scss
Outdated
@import url("https://cdn.jsdelivr.net/npm/@edx/brand-edx.org@alpha/dist/core.min.css"); | ||
@import url("https://cdn.jsdelivr.net/npm/@edx/brand-edx.org@alpha/dist/light.min.css"); | ||
@import "@edx/paragon/styles/scss/core/core"; | ||
@import "@edx/paragon/styles/css/themes/light/index.css"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[clarification] As is, I believe these would be importing duplicate styles? For example, @import "@edx/paragon/styles/css/themes/light/index.css";
is largely the same import as @import url("https://cdn.jsdelivr.net/npm/@edx/brand-edx.org@alpha/dist/light.min.css");
above.
If we're importing the core.css
and light.css
files via example/index.scss
, we should likely rely on the local imports from @edx/paragon
. Take a look at the draft migration documentation for an example of what I imagine MFEs would need to do to import the compiled Paragon CSS locally: https://openedx.atlassian.net/wiki/spaces/BPL/pages/3770744958/Migrating+MFEs+to+Paragon+design+tokens+and+CSS+variables#Using-locally-installed-Paragon-CSS
Alternatively, we could also consider configuring the example MFE to utilize the @edx/frontend-platform
approach to injecting the Paragon CSS from external CDN url like jsDelivr once openedx/frontend-platform#440 merges.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These imports have been changed, now it looks like this:
@use "@openedx/paragon/dist/core.min.css" as paragonCore;
@use "@openedx/paragon/dist/light.min.css" as paragonLight;
Alternatively, we could also consider configuring the example MFE to utilize the @edx/frontend-platform approach to injecting the Paragon CSS from external CDN url like jsDelivr once openedx/frontend-platform#440 merges.
We will get a working version for testing here: openedx/frontend-app-discussions#723
src/index.scss
Outdated
@import url("https://cdn.jsdelivr.net/npm/@edx/brand-edx.org@alpha/dist/core.min.css"); | ||
@import url("https://cdn.jsdelivr.net/npm/@edx/brand-edx.org@alpha/dist/light.min.css"); | ||
@import "@edx/paragon/styles/scss/core/core"; | ||
@import "@edx/paragon/styles/css/themes/light/index.css"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should consider whether there are any performance concerns around coupling Paragon's styles with these shared components. For example, if both these component includes all of Paragon's CSS and the consuming MFE includes all of Paragon's CSS, will the user essentially need to download all of Paragon's CSS twice?
I'm wondering if it would make sense for the shared components to be de-coupled from Paragon styles, with the assumption that these components will always be used within an application that provides Paragon styles externally from the component. A potential concern with this proposed approach may be around versioning; that is, is there a risk that developers could run into version discrepancies between what this component expects/uses and what version of Paragon's CSS is provided by the consuming/hosting MFE?
If we do leave Paragon styles coupled with the shared component, it may be a good to exercise to quantify/benchmark the performance implications of both approaches?
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I feel like we should de-couple Paragon styles from these components. The biggest problem with leaving Paragon's styles here is that we're dealing with CSS now - if we import Paragon's CSS variables here, then they will override all CSS variables from MFE's Paragon and this will affect the whole MFE (it will happen because header / footer styles are usually imported last in the MFE). This will basically mean that header component is in charge of the theme for the whole platform.
And even if we switch import order in the MFE, it will just mean that MFE will override all CSS used by header component.
I think if we're migrating to CSS, then MFEs should be a single source of truth for the styles in the platform. People should also understand that they cannot override CSS variables in their styles because that will likely affect this variable across all styles.
As for the problem with version discrepancies... The first thing we could do is to advise engineers to only use global tokens from Paragon in SCSS files in header / footer components as they are less likely to change in Paragon. But the main problem is with components I guess, because they use CSS classes from Paragon which are a lot likely to change between versions, not sure what to do here. The only long-term solution that comes to mind is to de-couple header / footer components even further from Paragon and just do not use Paragon's component's here at all. And create new components that will re-use only Paragon's CSS variables so that Paragon would still control the theme of the header / footer.
Another idea is to move header and footer components into Paragon so they always share the version? I might be crazy though haha
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that in 2025 we have already decided to abandon the imports of styles provided by Paragon and have completely trusted the single source of styles - MFE.
A potential concern with this proposed approach may be around versioning; that is, is there a risk that developers could run into version discrepancies between what this component expects/uses and what version of Paragon's CSS is provided by the consuming/hosting MFE?
Such a problem can occur. Perhaps with the advent of Webpack Module Federation, we will be able to eliminate the version control issues for our microfrontends and manage/update all dependencies from a single place. At the moment, the only way, as it seems to me, to identify and fix potential issues is to visually check the correctness of the header display. Fortunately, it is just a small component.
example/index.scss
Outdated
@import "@edx/brand/paragon/overrides"; | ||
@import url("https://cdn.jsdelivr.net/npm/@edx/brand-edx.org@alpha/dist/core.min.css"); | ||
@import url("https://cdn.jsdelivr.net/npm/@edx/brand-edx.org@alpha/dist/light.min.css"); | ||
@import "@edx/paragon/styles/scss/core/core"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be importing the core.css
rather than SCSS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Diana corrected it and now we have this version: 4ef75fe
@use "@openedx/paragon/dist/core.min.css" as paragonCore;
@use "@openedx/paragon/dist/light.min.css" as paragonLight;
@import "@edx/frontend-component-header/index";
package.json
Outdated
@@ -55,7 +55,7 @@ | |||
"redux-saga": "1.2.3" | |||
}, | |||
"dependencies": { | |||
"@edx/paragon": "20.44.0", | |||
"@edx/paragon": "21.0.0-alpha.38", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider moving this to a peer dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved and updated - "@openedx/paragon": ">= 23.0.0",
180a7fb
to
c264b1b
Compare
c264b1b
to
8a7607e
Compare
8a7607e
to
dc84f97
Compare
This PR purpose is to test/demo parago design tokens simliar to this one for the profile openedx/frontend-app-profile/pull/764 it override the following depns as seen in package.json - paragon alpha - openedx/frontend-build/pull/365 - openedx/frontend-platform/pull/440 - openedx/frontend-component-header/pull/351 - openedx/frontend-component-footer/pull/303 Conclousion so far: - There is an extra library that learning depends on which needs to support paragon; `frontend-lib-learning-assistant` and also `frontend-lib-special-exams` - It would be great to have a gudie or a document to look at, while doing the conversion that would **map variable from who it was used/named before to the name in design tokens** - I was stuck in the end with compliation error, that wepack couldn't find `Modal` exported from paragon.
Hey @PKulkoRaccoonGang, What is the current status of this PR, is it ready to review and merge? |
@Mashal-m Hello! At the moment, all pull requests opened in the edx and openex repositories are awaiting further action on the use of Paragon design tokens in the MFE. Don't pay any attention to them for now. Full list of pull requests that should just be open for now: |
cfca879
to
1580c3c
Compare
93f95e5
to
d2bf693
Compare
6a76c71
to
c139df5
Compare
package.json
Outdated
@@ -38,7 +38,7 @@ | |||
"@edx/frontend-platform": "8.1.5", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Important
Update frontend-platform to a version compatible with paragon 23
needs openedx/frontend-platform#689 to be merged
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved this message to the PR description, thanks!
b8b890b
to
dc80618
Compare
dc80618
to
f239827
Compare
Important
Update
frontend-platform
to a version compatible with Paragon 23.Needs openedx/frontend-platform#689 to be merged.
Issue: openedx/paragon#2348