docs: ADR that proposes a common stylesheet for all MFEs #351

xitij2000 · 2022-07-06T05:50:59Z

Description:

Adds an ADR that proposes creating a single common stylesheet that all MFEs load from a central place.

Merge checklist:

Consider running your code modifications in the included example app within frontend-platform. This can be done by running npm start and opening http://localhost:8080.
Consider testing your code modifications in another local micro-frontend using local aliases configured via the module.config.js file in frontend-build.
Verify your commit title/body conforms to the conventional commits format (e.g., fix, feat) and is appropriate for your code change. Consider whether your code is a breaking change, and modify your commit accordingly.

Post merge:

After the build finishes for the merged commit, verify the new release has been pushed to NPM.

openedx-webhooks · 2022-07-06T05:51:01Z

Thanks for the pull request, @xitij2000! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

supporting documentation
Open edX discussion forum threads
timeline information ("this must be merged by XX date", and why that is)
partner information ("this is a course on edx.org")
any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

codecov · 2022-07-06T05:53:10Z

Codecov Report

Patch and project coverage have no change.

Comparison is base (26001c9) 83.05% compared to head (f1b7440) 83.05%.
Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #351   +/-   ##
=======================================
  Coverage   83.05%   83.05%           
=======================================
  Files          40       40           
  Lines        1062     1062           
  Branches      195      195           
=======================================
  Hits          882      882           
  Misses        168      168           
  Partials       12       12

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

xitij2000 · 2022-07-07T15:39:40Z

Demo instance using a similar mechanism to load a theme: https://apps.bb4693.sandbox.opencraft.hosting/discussion/course-v1:edX+DemoX+Demo_Course/posts

xitij2000 · 2022-07-08T12:54:44Z

docs/decisions/0007-compile-common-theme-for-all-mfes.rst

+The mechanism for loading this common stylesheet will need to be different from
+the mechanism for loading the MFE stylesheet. A JavaScript theme loader will
+contain the location of the SCSS file and will add this stylesheet to the
+document.


The exact mechanism of this is currently not in this ADR but will be the subject of another ADR if this is accepted.

The prototype presented here uses Webpack's module federation, however for the purpose of just a single stylesheet, this may be an overkill. It might make sense to create a specific loader for this.

bradenmacdonald

As I understand it, one of the big benefits of MFEs is the ability to very quickly iterate on an individual MFE and deploy changes. Can you talk about that in the context of this ADR? e.g. does this ADR require that all MFEs are using the same version of Paragon, or is it still possible for one MFE to be using a newer version of Paragon (and newer common CSS) while other MFEs haven't yet been updated (and so use a different common CSS file?). And in that case, if multiple MFEs can use different versions of the common CSS file, are theme updates still faster?

docs/decisions/0007-compile-common-theme-for-all-mfes.rst

bradenmacdonald · 2022-07-15T03:06:11Z

docs/decisions/0007-compile-common-theme-for-all-mfes.rst

+  file names change, ensuring that a file is cached as long as it's used but not
+  loaded any more once the file contents change.
+
+  Since the common theme needs to have a fixed name, we can't rely on changing


This confused me at first. I think what you're saying is "Without using a JavaScript based loader on the client side, and without support for pre-rendering our MFEs on the server side, we would need to use a fixed URL/filename for the common CSS file, which would cause problems with caching that file."

Because in your actual ADR, the common theme does not need to have a fixed name ("now it can be a file with
the hash in its name").

Yeah, I think I might not have been very clear about this.

Currently, the file names generated for all the static content have a hash in the name, which allows indefinite caching. However, if you need to have the SCSS in a common location known to all MFEs in advance, this file name cannot change with each update, otherwise you'd need to redeploy all MFEs anyway. So you need a fixed static URL.

However, if the fixed static URL is the stylesheet itself, it will be a large file that cannot be cached, otherwise updating the stylesheet will not work as well and will require the cache to expire before updates show up.

So the idea is to have a small simple JavaScript loader that is never cached, and contains the location of this SCSS file which does have a hash in its name. This way only a minimum size is uncached and the rest can be cached.

docs/decisions/0007-compile-common-theme-for-all-mfes.rst

xitij2000 · 2022-07-18T09:36:50Z

As I understand it, one of the big benefits of MFEs is the ability to very quickly iterate on an individual MFE and deploy changes. Can you talk about that in the context of this ADR? e.g. does this ADR require that all MFEs are using the same version of Paragon, or is it still possible for one MFE to be using a newer version of Paragon (and newer common CSS) while other MFEs haven't yet been updated (and so use a different common CSS file?). And in that case, if multiple MFEs can use different versions of the common CSS file, are theme updates still faster?

I've experimented with this a bit, and in my experience things work pretty well even with different versions of Paragon across MFEs. That said, there can be sources if issues, one being the following situation:

There is a bug in a Paragon component that requires a JavaScript and CSS fix. The version of Paragon including the bug fix is updated for a particular MFE, but not for the common theme. So the JavaScript for the Paragon bug fix does get deployed, but not the CSS code.

I think it will be important to keep Paragon in the common theme pinned to the latest version used by all MFEs, and to redeploy the common theme each time an MFE is updated and redeployed if it includes an update to Paragon.

bradenmacdonald · 2022-07-18T21:59:31Z

There is a bug in a Paragon component that requires a JavaScript and CSS fix. The version of Paragon including the bug fix is updated for a particular MFE, but not for the common theme. So the JavaScript for the Paragon bug fix does get deployed, but not the CSS code.

Hmm, that does seem like a significant drawback. Could it make sense to include the JS and CSS together in the common theme code, so that they're always in sync at least?

Also: It seems that the main benefits of this ADR accrue when someone is actively editing or updating themes. But I imagine for each given Open edX instance, that will only occur occasionally (e.g. when first setting the instance up), and 99% of the time it will be operated and maintained without anyone making changes to theming. (Or is that a wrong assumption?). If so, would it make sense to have a kind of "theming mode" where this ADR's functionality is enabled, but otherwise leave it off for normal operations and faster deployment of MFE updates? Or alternatively, would it make sense to use the approach specified in this ADR for instances using named release versions (favoring rapid theming, and where MFEs are probably using the same Paragon version anyways), but use the current method for instances that are deployed continuously (favoring flexibility, accuracy, and rapid iteration for each individual MFE)?

xitij2000 · 2022-07-19T07:09:30Z

There is a bug in a Paragon component that requires a JavaScript and CSS fix. The version of Paragon including the bug fix is updated for a particular MFE, but not for the common theme. So the JavaScript for the Paragon bug fix does get deployed, but not the CSS code.

Hmm, that does seem like a significant drawback. Could it make sense to include the JS and CSS together in the common theme code, so that they're always in sync at least?

This is possible if we just use module federation for the theme, i.e. have a branded-paragon module that is loaded by all MFEs. This module can include the branding package + Paragon. However, I think this will require major changes to all MFEs since they will need to now load Paragon from a share module vs from an standard import. Maybe this could be handled in frontend-build or frontend-platform, but even so, a bigger change.

Another simpler solution is to switch to using CSS variables in Paragon. In this case Paragon no long needs to be built with the theme but can be built and loaded independently by each MFE. However, this reduces the benefits of consolidating the theme in the first place.

I think we can also simplify this with build automation. i.e. part of the MFE deployment pipeline can be to trigger a rebuild of the common theme. This common theme can have versions pinned such that it always takes the latest version of the branding package, and can have hooks that update the common theme to always have the latest version of Paragon that is used by any MFE (not the latest released version, the latest used version).

Also: It seems that the main benefits of this ADR accrue when someone is actively editing or updating themes. But I imagine for each given Open edX instance, that will only occur occasionally (e.g. when first setting the instance up), and 99% of the time it will be operated and maintained without anyone making changes to theming. (Or is that a wrong assumption?).

That is not entirely wrong if we take this ADR in isolation, but I also don't see this as a stand-alone thing. For example, in combination with the configuration API ADR, you can have a multi-tenent setup, each site having a separate theme.

If so, would it make sense to have a kind of "theming mode" where this ADR's functionality is enabled, but otherwise leave it off for normal operations and faster deployment of MFE updates?

That is mentioned in passing in this ADR, i.e. that the existing mechanism will continue to be supported. If you don't provide a config variable for the common theme location, then it will build and use the theme the way it does now.

Or alternatively, would it make sense to use the approach specified in this ADR for instances using named release versions (favoring rapid theming, and where MFEs are probably using the same Paragon version anyways), but use the current method for instances that are deployed continuously (favoring flexibility, accuracy, and rapid iteration for each individual MFE)?

I had another idea, but it needed more investigation, which was to have the Paragon version included in the common theme code. Then the MFE can decide to load the common theme or the theme it comes with. If the MFE uses a newer version of Paragon than is provided by the common theme, then it can load the CSS it comes with. Both of these will be built with the latest variables so should be intact. The next time the main theme is rebuilt it will have a newer version and as such it will once again be used.

That said, I think all this will need separate investigation and a separate ADR. I hoped to keep this initial ADR simple and focussed on one thing.

bradenmacdonald · 2022-07-19T23:09:47Z

Cool. Sorry if I muddied the waters :p

xitij2000 · 2022-07-20T08:24:25Z

Cool. Sorry if I muddied the waters :p

I am very grateful for the feedback! I think it will help clarify the ADR a lot more, and flesh out more clearly the caveats in this approach.

natabene · 2022-07-20T19:54:58Z

@xitij2000 Thank you for your contribution. Please let me know once this is ready for a review.

felipemontoya

I like the proposal of this ADR. As always, the detail of the implementation will be the critical factor but the proposed road looks good to me.

felipemontoya · 2022-07-28T14:56:29Z

docs/decisions/0007-compile-common-theme-for-all-mfes.rst

+directly. This means that if different versions of Paragon are used for an MFE
+vs the common theme, then there is a chance that an incompatible version of the
+CSS could be loaded for the MFE. This will make it all the more important to
+ensure that version of Paragon used across all MFEs is compatible. This will be


I am imagining that making paragon compatible only happens one time. Before a mfe uses this compatible version of paragon then it is business as usual. After, they are loading the common css and that is it.

Do you foresee that there could be other moments where compatibility is broken?

I'm not sure I understood what you meant by "making paragon compatible only happens one time".

I think the issue I'm looking at is as follows:

A bug is encountered in a Paragon component. For example if a label/text for some component is longer than a certain threshold, it will break the UI.

The fix for this involves some React code and a change in SCSS.

The common compiled theme is built on an older version of Paragon that doesn't include this fix.

An MFE is updated to include a newer version of Paragon.

The MFE is now using React code, but it's supporting CSS code isn't available in the theme.

This would need the common theme to be rebuilt as well, using the latest Paragon.

I understand now. I thought you were the initial compatibility change, but this issue will come about constantly.

felipemontoya · 2022-07-28T14:59:19Z

docs/decisions/0007-compile-common-theme-for-all-mfes.rst

+By continuing to support the existing theming mechanism, the current mechanism
+for theming can continue working for those who need it.
+
+Since there is a JavaScript-based loader involved, there is potential for


I think that getting it right for the loader is the gist of this proposal.

Would it be possible that there is more than a loader written and which loader is used is also a configuration? I am looking at this from the lens of multitenancy probably requiring a more complex/slower loader which not everyone should pay the penalty for.

In this proposal I imagine that the loader can be as simple as:

const urlOfThemeCSS= '...'; addCSSStyleSheet(urlOfThemeCSS);

Where the function will essentially create a link element to load the stylesheet. In addition, it can have a simple API to signal to the app when the theme has loaded.

I think a good path for multi-tenancy would be to combine this with the great work being done on runtime configuration: openedx/wg-frontend#103

Since the loader path is a config variable, and the runtime configuration can provider URLs that vary based on the site, it would allow pointing to different themes. The loader itself can just remain simple, if that makes sense.

What you are saying then is that the loader sis so simple that there will be no need for more than one. If the loader ends up being something so flexible, then the config variable will take care of everything.

I was trying to avoid a situation where there is already logic baked into the loader that makes it imposible to extend via configuration. It does not look like that is the case though.

The loader ideally needs to be simple, since the idea is that it won't be cached. So the smaller it is the better.

Right now the scss name is baked into the index.html file. If the stylesheet needs to load dynamically we can't do that. So we need some way to dynamically determine the name of this stylesheet file. One mechanism is to have a more complex API that returns the stylesheet location. An alternative is to have a small javascript file (the loader) that has the location of the stylesheet in it. Whenever the stylesheet location changes this file will be updated, and it will always be reloaded, so we get the latest stylesheet.

So making the loader heavy would be detrimental to the loading speed, though there is probably nothing stopping people from doing it.

So in the html we would have:

<!DOCTYPE html> <html> <head> <script type="text/javascript" src="loaderfile_with_no_cache.js"></script> <script type="text/javascript" src="long_react_code.123HASH134.js"></script> </head>

And if someone wants to override the loader, they can go and configure the thing to load the file from anywhere else?

e.g:

<!DOCTYPE html> <html> <head> <script type="text/javascript" src="different/path/custom_loaderfile_with_no_cache.js"></script> <script type="text/javascript" src="long_react_code.123HASH134.js"></script> </head>

@felipemontoya I think we'd load the loader itself dynamically, and just append the current timestamp as a query parameter to break the cache.

However, the location of this loader would be a config variable provided during build, or with the runtime configuration mechanism dynamically during runtime.

dcoa · 2022-08-01T17:35:27Z

docs/decisions/0007-compile-common-theme-for-all-mfes.rst

+	@import "~@edx/paragon/scss/core/core";
+	@import "~@edx/brand/paragon/overrides";
+
+These four lines, import the Paragon and bootstrap code and apply


Hi @xitij2000, I think this is a good idea with the actual status of the theming.

I was wondering about the header, footer, and cookie banner styles, that should be updated to use CSS variables, update the version in the MFE and be part of the MFE stylesheet or could be part of the theme stylesheet?

I think the header, footer, cookie banner and other elements shoudl also over time be updated to use CSS variables. They can then be independent stylesheets that are loaded for those.

So we'd have:

Base theme stylesheet (loaded from a common source)

Component stylesheets (header, footer, banner etc. separate for each MFE)

MFE stylesheet (separate for each MFE).

xitij2000 · 2023-01-20T13:21:35Z

That said, during local development, I believe we may want to strive for being able to run child MFEs independent of the container SPA (if possible), e.g. if I'm not making changes to the container SPA, my dev environment ideally shouldn't need to run it (or at least a local copy of it).

I think this will depend a lot on the mechanism being used for this. I was experimenting on an approach using a monorepo for all learner MFEs using npm workspaces. i.e. each MFE is a package inside a larger global repo, with MFEs loading each other using module federation. This, if set up properly would allow using each MFE individually, but also via the container SPA.

If the mechanism that's finally settled on is similar, then it might still be possible to have the theme installed and built for the container SPA but still use and reference it in individual MFEs.

For other approaches, I agree, the approach for individual MFEs in local development can remain much the same, i.e. build a local copy of the branding package point the individual MFE to it.

mphilbrick211 · 2023-02-06T23:21:36Z

Hi @xitij2000 and @arbrandes just checking in on this :)

arbrandes · 2023-02-07T17:17:59Z

@mphilbrick211, @xitij2000 might have more to say, but I believe this is in the backburner, pending further development on openedx/open-edx-proposals#410 and openedx/paragon#1546. Both will have a significant impact on how theming will be done in the future.

adamstankiewicz · 2023-02-15T23:16:57Z

[inform/update] @viktorrusakov and I put together a prototype of what we imagine could work to dynamically load common stylesheet(s) generated by Paragon's design tokens into MFEs might look like: #440

The idea being that Paragon is going to compile its own CSS now with the recommendation to host it externally on a CDN (technically, even an open source CDN like jsdelivr or unpkg would work here).

Would love any feedback on the proposed approach in the above PR.

tl;dr;

it 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 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 themes), 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 setAppThemeVariant('dark') in the future once more theme variants beyond "light" is supported.

cc @xitij2000 @arbrandes

mphilbrick211 · 2023-03-09T20:24:17Z

@arbrandes @adamstankiewicz just checking in on this to see if there are any updates.

xitij2000 · 2023-03-10T14:23:34Z

@arbrandes @adamstankiewicz just checking in on this to see if there are any updates.

I think the new PR linked by @adamstankiewicz above makes it possible to implement this in practice, however I'm still not up to date on the modular MFE discovery and whether it resolves the issue of different MFEs using different version of Paragon.

With that PR some of the reasons for using a JavaScript loader are no longer applicable. Since the variables.css file is likely to be much smaller, it might be OK for it to have a short caching period, so it can be quickly updated. Or, with each variable a random query param can be added to the config API response so that the URL is forcefully refreshed.

arbrandes · 2023-03-10T16:28:09Z

@xitij2000

(...) not up to date on the modular MFE discovery and whether it resolves the issue of different MFEs using different version of Paragon.

That's one of the first goals to solve, but we don't have the details, yet. But it's heading towards a world where MFEs will be encouraged to use Paragon from the containing SPA, but we won't be able to force them to do it. (This entails Paragon being very careful about backwards compatibility, but we knew that from the get-go.)

Given that not using a global Paragon will likely exclude the MFE from features such as the one proposed in this PR, I expect all of them - or at least, all of the ones where this feature would be important - to follow the same pattern.

xitij2000 · 2023-03-13T07:17:23Z

@xitij2000

(...) not up to date on the modular MFE discovery and whether it resolves the issue of different MFEs using different version of Paragon.

That's one of the first goals to solve, but we don't have the details, yet. But it's heading towards a world where MFEs will be encouraged to use Paragon from the containing SPA, but we won't be able to force them to do it. (This entails Paragon being very careful about backwards compatibility, but we knew that from the get-go.)

Given that not using a global Paragon will likely exclude the MFE from features such as the one proposed in this PR, I expect all of them - or at least, all of the ones where this feature would be important - to follow the same pattern.

Do you think it makes sense to update this discovery to take into account the recent developments with style dictionary, and @adamstankiewicz's PR: #440, given that the goal of modular MFEs is already to align all MFEs to the same version of paragon?

I'm planning to go through the modular MFE discovery soon to familiarise myself with it as well.

arbrandes · 2023-03-13T11:39:00Z

@xitij2000,

Do you think it makes sense to update this discovery to take into account the recent developments with style dictionary

We're very much taking it into account, yes! :)

mphilbrick211 · 2023-04-24T20:26:53Z

Hi @arbrandes and @xitij2000 - just following up to see if there's an update here?

xitij2000 · 2023-04-25T09:45:58Z

Hi @arbrandes and @xitij2000 - just following up to see if there's an update here?

I'm going to spend some time updating this PR this week so it aligns better with the latest developments.

xitij2000 · 2023-04-26T13:08:14Z

Hi @arbrandes and @xitij2000 - just following up to see if there's an update here?

I've updated the PR to more closely match the current implementation.

mphilbrick211 · 2023-06-01T14:30:26Z

Just checking in on this @xitij2000 :)

xitij2000 · 2023-06-02T14:34:50Z

Just checking in on this @xitij2000 :)

I had updated it to match the new implementation as of that comment. If there have been further changes I will allocate some time next week to update it again.

mphilbrick211 · 2023-08-22T19:02:34Z

Hi @xitij2000 and @arbrandes! Just checking in on this :)

Adds an ADR that proposes creating a single common stylesheet that all MFEs load from a central place.

xitij2000 · 2023-08-30T09:41:12Z

Hi @xitij2000 and @arbrandes! Just checking in on this :)

I've updated the ADR to match changes, however I think it might be better to wait till that work is over, and have @adamstankiewicz work on this doc since I'm no longer fully up to date on the nuances of the recent changes.

mphilbrick211 · 2023-10-03T01:24:38Z

Hi @xitij2000 and @arbrandes! Just checking in on this :)

I've updated the ADR to match changes, however I think it might be better to wait till that work is over, and have @adamstankiewicz work on this doc since I'm no longer fully up to date on the nuances of the recent changes.

Hi @xitij2000 @adamstankiewicz - checking back in on this :)

xitij2000 · 2023-10-26T09:08:43Z

Hi @xitij2000 and @arbrandes! Just checking in on this :)

I've updated the ADR to match changes, however I think it might be better to wait till that work is over, and have @adamstankiewicz work on this doc since I'm no longer fully up to date on the nuances of the recent changes.

Hi @xitij2000 @adamstankiewicz - checking back in on this :)

Sorry I haven't had much time to check into this due to time off recently. I don't think the PR this is tracking has changed since I last updated this ADR.

Mashal-m · 2023-11-17T07:33:42Z

Hey @xitij2000 , What is the current status of this PR, is it ready to review and merge?

xitij2000 · 2023-11-20T12:35:26Z

I am going to close this PR for now and look into it when the paragon PRs are closer to final.

openedx-webhooks · 2023-11-20T12:35:30Z

@xitij2000 Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.

openedx-webhooks · 2023-11-20T12:35:31Z

@xitij2000 Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.

openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Jul 6, 2022

xitij2000 mentioned this pull request Jul 7, 2022

Frontend Working Group Meeting 2022-07-07 openedx/wg-frontend#111

Closed

arbrandes self-requested a review July 7, 2022 15:23

arbrandes mentioned this pull request Jul 7, 2022

Evaluate OpenCraft's dynamic theme loading proposals openedx/axim-engineering#284

Closed

xitij2000 commented Jul 8, 2022

View reviewed changes

bradenmacdonald reviewed Jul 15, 2022

View reviewed changes

xitij2000 force-pushed the kshitij/common-theme-adr branch from a0d2e5c to 48146c1 Compare July 21, 2022 09:27

This was referenced Jul 21, 2022

Frontend Working Group Meeting 2022-07-21 openedx/wg-frontend#113

Closed

Frontend Working Group Meeting 2022-07-28 openedx/wg-frontend#117

Closed

felipemontoya approved these changes Jul 28, 2022

View reviewed changes

dcoa reviewed Aug 1, 2022

View reviewed changes

arbrandes mentioned this pull request Aug 4, 2022

Frontend Working Group Meeting 2022-08-04 openedx/wg-frontend#118

Closed

This was referenced Aug 15, 2022

Create a theming system that replaces comprehensive theming for the current Tutor-supported MFEs openedx/axim-engineering#418

Open

Figure out a way to apply theme changes without requiring a full container rebuild openedx/axim-engineering#420

Open

This was referenced Aug 18, 2022

Frontend Working Group Meeting 2022-08-18 openedx/wg-frontend#121

Closed

Frontend Working Group Meeting 2022-08-25 openedx/wg-frontend#122

Closed

arbrandes mentioned this pull request Sep 1, 2022

Frontend Working Group Meeting 2022-09-01 openedx/wg-frontend#123

Closed

This was referenced Sep 30, 2022

Kick off meeting with UX stakeholders openedx/axim-engineering#477

Closed

Frontend Working Group Meeting 2022-10-06 openedx/wg-frontend#132

Closed

arbrandes mentioned this pull request Oct 13, 2022

Frontend Working Group Meeting 2022-10-13 openedx/wg-frontend#133

Closed

arbrandes assigned xitij2000 Oct 17, 2022

adamstankiewicz mentioned this pull request Feb 16, 2023

feat: adds support for loading external theme CSS for MFEs #440

Closed

4 tasks

xitij2000 force-pushed the kshitij/common-theme-adr branch from 48146c1 to 95837f5 Compare April 25, 2023 12:57

arbrandes mentioned this pull request Jun 13, 2023

Adolfo's reviews openedx/axim-engineering#696

Closed

xitij2000 added 3 commits August 30, 2023 14:11

docs: ADR that proposes a common stylesheet for all MFEs

ce9494e

Adds an ADR that proposes creating a single common stylesheet that all MFEs load from a central place.

squash!: Update ADR to reflech WIP openedx#440

9065b37

docs: Update ADR to match implementation changes

f1b7440

xitij2000 force-pushed the kshitij/common-theme-adr branch from 95837f5 to f1b7440 Compare August 30, 2023 09:38

xitij2000 closed this Nov 20, 2023

docs: ADR that proposes a common stylesheet for all MFEs #351

docs: ADR that proposes a common stylesheet for all MFEs #351

Conversation

xitij2000 commented Jul 6, 2022

openedx-webhooks commented Jul 6, 2022 • edited Loading

codecov bot commented Jul 6, 2022 • edited Loading

Codecov Report

xitij2000 commented Jul 7, 2022

Choose a reason for hiding this comment

bradenmacdonald left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xitij2000 commented Jul 18, 2022

bradenmacdonald commented Jul 18, 2022 • edited Loading

xitij2000 commented Jul 19, 2022

bradenmacdonald commented Jul 19, 2022

xitij2000 commented Jul 20, 2022

natabene commented Jul 20, 2022

felipemontoya left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felipemontoya Aug 10, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xitij2000 commented Jan 20, 2023

mphilbrick211 commented Feb 6, 2023

arbrandes commented Feb 7, 2023

adamstankiewicz commented Feb 15, 2023 • edited Loading

mphilbrick211 commented Mar 9, 2023

xitij2000 commented Mar 10, 2023

arbrandes commented Mar 10, 2023

xitij2000 commented Mar 13, 2023

arbrandes commented Mar 13, 2023

mphilbrick211 commented Apr 24, 2023

xitij2000 commented Apr 25, 2023

xitij2000 commented Apr 26, 2023

mphilbrick211 commented Jun 1, 2023

xitij2000 commented Jun 2, 2023

mphilbrick211 commented Aug 22, 2023

xitij2000 commented Aug 30, 2023

mphilbrick211 commented Oct 3, 2023

xitij2000 commented Oct 26, 2023

Mashal-m commented Nov 17, 2023

xitij2000 commented Nov 20, 2023

openedx-webhooks commented Nov 20, 2023

openedx-webhooks commented Nov 20, 2023

openedx-webhooks commented Jul 6, 2022 •

edited

Loading

codecov bot commented Jul 6, 2022 •

edited

Loading

bradenmacdonald commented Jul 18, 2022 •

edited

Loading

felipemontoya Aug 10, 2022 •

edited

Loading

adamstankiewicz commented Feb 15, 2023 •

edited

Loading