Skip to content
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

OEP-XXXX: Micro-frontend Customization #259

Closed
wants to merge 1 commit into from

Conversation

davidjoy
Copy link
Contributor

@davidjoy davidjoy commented Nov 8, 2021

@davidjoy davidjoy force-pushed the djoy/mfe-customization branch from 04e465c to 6fc4e8b Compare November 8, 2021 21:36
@davidjoy davidjoy force-pushed the djoy/mfe-customization branch from 6fc4e8b to ce15f29 Compare November 8, 2021 21:37

We avoid using semantic CSS classes where possible, in favor of utility classes. We can't guarantee that semantic CSS classes applied to elements will always be present.

One thing worth noting about the styling customization process is that it must happen at build-time, since we don't ship any SASS to the client, nor is there any run-time SASS compilation in use. This means that operators who want to run multiple brands on a single instance of the platform must independently deploy the micro-frontend multiple times, once with each brand.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've investigated this a bit and I feel if the MFEs avoid using any SCSS that needs theme information, we can build a common scss file that can be rebuild and deployed independently of the MFE. This would mean that you need to pre-build a theme, but can swap it out in real-time. So end-users could potentially be given a light-theme/dark-theme option or a separate service could rebuild the theme and replace it without needing all MFEs to be redeployed.

@feanil
Copy link
Contributor

feanil commented Aug 1, 2022

@davidjoy @xitij2000 what's the status of this OEP, should it be closed for now or is it gonna come out of draft some time soon?

@davidjoy
Copy link
Contributor Author

davidjoy commented Aug 1, 2022

Sadly this isn't on my radar these days, but I still believe in this vision. I'd hate to see this work lost (but maybe it already is). @arbrandes do you have any interest in picking this up? Same question will go for #287

@arbrandes
Copy link
Contributor

As noted on Slack and recorded here for future reference, this is indeed still on the table. In prioritizing the (several) possible MFE initiatives, this lands squarely in the top 3: see this cell on the priorities document. This document will be ported over to issues on the Roadmap shortly.

@arbrandes
Copy link
Contributor

Oh, and I'll assign myself as official "pusher" here and on #287.

@arbrandes arbrandes self-assigned this Aug 5, 2022
@davidjoy
Copy link
Contributor Author

I'm going to close this OEP out for now just to clean up. @arbrandes, feel free to reopen if you think we'll make progress here. Unfortunately I don't have the bandwidth to contribute.

@davidjoy davidjoy closed this Jan 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants