-
Notifications
You must be signed in to change notification settings - Fork 66
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
feat: adds support for loading external theme CSS for MFEs #689
base: master
Are you sure you want to change the base?
Conversation
Thanks for the pull request, @dcoa! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #689 +/- ##
==========================================
+ Coverage 83.41% 86.71% +3.30%
==========================================
Files 40 48 +8
Lines 1073 1393 +320
Branches 197 292 +95
==========================================
+ Hits 895 1208 +313
- Misses 166 172 +6
- Partials 12 13 +1 ☔ View full report in Codecov by Sentry. |
aee582b
to
e81b549
Compare
5b4c843
to
ed293e3
Compare
@dcoa I'm getting an error during build related to the
I tried to solve it by changing the export to Have you encountered such a problem? |
@PKulkoRaccoonGang this is related to frontend-build changes, I'm checking right now This line is making that the app is not rendering in frontend-platform https://github.com/openedx/frontend-build/pull/546/files#diff-22e13ddf245ea4fa81ca4d686dddf46fa9cbf70fbbff99991cccbf0c8ff82316R175 If you remove it, you will be able to see the app. Update I made an update to webpack dev config for example app and is working now. |
9ebae07
to
94e4a62
Compare
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.
@dcoa This looks great! I have already started working on Update openedx/frontend-app-discussions
. I left a few questions about the operation of some features and the code in general.
a6a9211
to
229d79a
Compare
06fc4e6
to
837858e
Compare
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.
Overall this is looking great! I left a suggestion to clarify the documentation is referring to design tokens, and a few comments noting PRs that need to land before this can.
Thank you so much for this!
@@ -0,0 +1,250 @@ | |||
# Theming support with `@openedx/paragon` and `@openedx/brand-openedx` |
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.
# Theming support with `@openedx/paragon` and `@openedx/brand-openedx` | |
# Theming support with `@openedx/paragon` and `@openedx/brand-openedx` | |
> [!IMPORTANT] | |
> This document describes theming with design tokens. | |
> Information on theming MFEs that do not yet have design tokens support: | |
> * https://github.com/openedx/brand-openedx | |
> Information on the design tokens project: | |
> * https://github.com/openedx/paragon/blob/master/docs/decisions/0019-scaling-styles-with-design-tokens.rst | |
> * https://github.com/openedx/paragon/tree/alpha?tab=readme-ov-file#design-tokens |
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.
2565f02
to
ae5b53f
Compare
4204364
to
45642c7
Compare
if (!paragonThemeState?.isThemeLoaded) { | ||
return null; | ||
} |
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.
[sanity check] Given when this code path is executed, the entire MFE app is rendered as a blank white screen, I'm wondering if we have sufficient observability for when we return null
here, after any actual async loading has finished/resolved.
For example, if there's an issue with the CDN and we also fail to fallback to using the CSS source files from the locally installed @openedx/paragon
and @edx/brand
packages, and the MFE returns a blank white screen, will we sufficiently get alerted to it via logError
, etc.?
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 have enough paths for logging potential errors during the loading, I will working on the testing that will help to cover that cases and potentially identify if some validation is missing
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.
From discussion during Paragon WG:
- logging in
useEffect
to avoid duplicate logs - differentiate between error state and loading state
- @brian-smith-tcril to look into what logs show up in the console for existing error states to get a sense of a reasonable logging strategy for this
- possible future improvement (once React 18 support lands) - use suspense?
logError(`Failed to load core theme CSS from ${url}`); | ||
if (isFallbackThemeUrl) { | ||
logError(`Could not load core theme CSS from ${url} or fallback URL. Aborting.`); |
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.
[curious] Any concerns around having two logError
function calls within the same code path? I.e., if isFallbackThemeUrl
is truthy here, would we have logged basically the same error twice (with slightly differing error messages)?
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 we just left the isFallbackThemeUrl
and relay on the fallback logInfo as the can not load the default URL?
We can have a first message (in the logInfo
- we also can replace it with a logError
) that is
Could not load core theme CSS from ${url}. Falling back to locally installed core theme CSS: ${coreThemeFallbackUrl}
and then with the isFallbackThemeUrl
the second message
Could not load core theme fallback URL. Aborting.
What do you think?
if (isBrandOverride) { | ||
setIsBrandThemeCoreLoaded(true); | ||
} else { | ||
setIsParagonThemeCoreLoaded(true); |
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.
[curious] Do we want to ensure coverage on the critical code paths within useParagonThemeCore
, e.g. around loading? There's a few CodeCov annotations about missing coverage.
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.
Yes, working on the overall coverage :)
logError(`Failed to load theme variant (${themeVariant}) CSS from ${value.urls.default}`); | ||
if (isFallbackThemeUrl) { | ||
logError(`Could not load theme variant (${themeVariant}) CSS from fallback URL. Aborting.`); |
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.
[curious] Similar question as above, regarding potential for calling logError
twice for largely the same error, when isFallbackThemeUrl
is truthy. Should we only call logError
once in this case?
logError(`Failed to load theme variant (${themeVariant}) CSS from ${value.urls.default}`); | ||
if (isFallbackThemeUrl) { | ||
logError(`Could not load theme variant (${themeVariant}) CSS from fallback URL. Aborting.`); | ||
if (isBrandOverride) { |
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.
Similar question around test coverage on some of the uncovered code paths within this hook.
45642c7
to
54c6e00
Compare
b2d3856
to
bc22970
Compare
@@ -137,6 +137,16 @@ function extractRegex(envVar) { | |||
return undefined; | |||
} | |||
|
|||
function parseParagonThemeUrls(paragonUrlsJson) { |
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 it makes sense to check for a falsy value before trying to parse. Not having process.env.PARAGON_THEME_URLS
set is not an error state, but should still return {}
.
Then, assuming we make it past the falsy check, we can go into the try/catch
. It would also be good to log errors that we catch in there.
I think specifically checking for err
being a SyntaxError
exception (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse#exceptions) would be good. So something like
try {
return JSON.parse(paragonUrlsJson);
} catch (err) {
if (err instanceof SyntaxError) {
// log something about not being able to parse the json and it possibly being invalid.
// maybe also log something about what to expect themes to look like when {} is returned
return {};
} else {
// not sure what to do here, if we're getting a different error type maybe we should just throw it?
}
}
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.
[curious] Currently {}
will not configure any URL (similar behavior as undefined
), do we expect (prefer) a different behavior (for example, try to load the default themes)?
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.
Discussed in Paragon WG: Following the same pattern as the CDN URLs being down (loading locally installed styles) seems like the best path forward here.
PARAGON_THEME_URLS |
Behavior |
---|---|
Doesn't exist (MFE choosing to use local styles) | Load local styles (from MFE's style entrypoint) |
Set, parses properly | Attempt to load from parsed URL(s), if error - fallback to local styles |
Set, fails to parse | Fallback to local styles (injected from frontend-platform - derived from node modules) |
a29f484
to
8300338
Compare
2179fbf
to
1cff3e4
Compare
@PKulkoRaccoonGang it looks like you have some unresolved comments from May of last year. Would you mind hitting the "Resolve conversation" button on the ones that don't require any more discussion or changes? |
@brian-smith-tcril I would love to, but I don’t have such a button. I think it’s because I don’t have the necessary permissions in this repository. |
@dcoa You can close all the comments I wrote where I added "Resolved" :) |
@PKulkoRaccoonGang sorry about that! Thanks for commenting on the ones that have been resolved! I went through and clicked the button on them. |
Co-authored-by: Brian Smith <[email protected]>
Description:
This PR updates the original one #440 closer to the master branch and adds some extra tests.
Please read the original PR for additional context.
Warning
Merge checklist:
frontend-platform
. This can be done by runningnpm start
and opening http://localhost:8080.module.config.js
file infrontend-build
.fix
,feat
) and is appropriate for your code change. Consider whether your code is a breaking change, and modify your commit accordingly.Post merge: