feat: configure style via MFE config api

[navinkarkera]

Description

This PR adds functionality to customize the footer using MFE config API to some extent. This allows users to customize the footer per site without creating multiple footer components.

Screenshots

Default look with no customization:

With MFE config:

MFE_CONFIG = {
    "FOOTER_CUSTOM_STYLE": {
        "backgroundImage": "url(https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTgb0Xw3iHTv4pobzu3cSStIU3txTxzC1LHNw&usqp=CAU)",
        # "backgroundImage": "linear-gradient( rgba(255, 255, 255, 0.85), rgba(255, 255, 255, 0.85) ) , url(https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQRyiCBR1eTfnv5UcqIKmEHZHLLHHQDt6PiZA&usqp=CAU)",
    },
    "FOOTER_CUSTOM_CLASSNAMES": "py-5 px-4 text-center flex-column justify-content-center flex-wrap text-dark",
    "FOOTER_LOGO_STYLE": {
        "marginBottom": "2rem",
    },
    "LOGO_TRADEMARK_URL": "https://lms.oc.eshe.opencraft.hosting/static/default-eshe-theme/images/logo.5a2f93a71b89.png",
    "FOOTER_LINKS": [
        {"url": "https://google.com", "text": "Terms of service"},
        {"url": "https://duckduckgo.com", "text": "Acceptable Use Policy"},
        {"url": "https://openedx.org", "text": "Privacy Policy"},
    ],
    "FOOTER_LINKS_CONTAINER_CLASSNAMES": "flex-wrap",
    "FOOTER_LINKS_CLASSNAMES": "text-dark font-weight-bold",
}

And removal of support languages parameter as shown in diff below:

diff --git a/example/index.jsx b/example/index.jsx
index 580fccc..403c3b2 100644
--- a/example/index.jsx
+++ b/example/index.jsx
@@ -16,11 +16,6 @@ subscribe(APP_READY, () => {
         config: getConfig(),
       }}>
         <Footer
-          onLanguageSelected={() => {}}
-          supportedLanguages={[
-            { label: 'English', value: 'en' },
-            { label: 'Español', value: 'es' },
-          ]}
         />
       </AppContext.Provider>
     </AppProvider>,

Results:

Result with no alignment changes:

Test instructions:

• Start lms in master devstack using make lms-up.
• Add below settings to lms/envs/private.py.

ENABLE_MFE_CONFIG_API = True
MFE_CONFIG = {}

• Clone this repo in some location and run npm install and npm run start.
• Visit http://localhost:8080/ to see default footer.
• Update settings in lms/envs/private.py as shown below:

ENABLE_MFE_CONFIG_API = True
MFE_CONFIG_API_CACHE_TIMEOUT = 0
MFE_CONFIG = {
    "FOOTER_CUSTOM_STYLE": {
        "backgroundImage": "url(https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTgb0Xw3iHTv4pobzu3cSStIU3txTxzC1LHNw&usqp=CAU)",
        # "backgroundImage": "linear-gradient( rgba(255, 255, 255, 0.85), rgba(255, 255, 255, 0.85) ) , url(https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQRyiCBR1eTfnv5UcqIKmEHZHLLHHQDt6PiZA&usqp=CAU)",
    },
    "FOOTER_CUSTOM_CLASSNAMES": "py-5 px-4 text-center flex-column justify-content-center flex-wrap text-dark",
    "FOOTER_LOGO_STYLE": {
        "marginBottom": "2rem",
    },
    "LOGO_TRADEMARK_URL": "https://lms.oc.eshe.opencraft.hosting/static/default-eshe-theme/images/logo.5a2f93a71b89.png",
    "FOOTER_LINKS": [
        {"url": "https://google.com", "text": "Terms of service"},
        {"url": "https://duckduckgo.com", "text": "Acceptable Use Policy"},
        {"url": "https://openedx.org", "text": "Privacy Policy"},
    ],
    "FOOTER_LINKS_CLASSNAMES": "text-dark font-weight-bold",
}

• [Optional] Remove language switcher from footer by removing below lines from example/index.jsx.

diff --git a/example/index.jsx b/example/index.jsx
index 580fccc..403c3b2 100644
--- a/example/index.jsx
+++ b/example/index.jsx
@@ -16,11 +16,6 @@ subscribe(APP_READY, () => {
         config: getConfig(),
       }}>
         <Footer
-          onLanguageSelected={() => {}}
-          supportedLanguages={[
-            { label: 'English', value: 'en' },
-            { label: 'Español', value: 'es' },
-          ]}
         />
       </AppContext.Provider>
     </AppProvider>,

• Visit http://localhost:8080/ again to see customized footer.

[openedx-webhooks]

Thanks for the pull request, @navinkarkera! 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]

Codecov Report

Patch coverage: 100.00% and project coverage change: +2.96% 🎉

Comparison is base (197f24a) 81.25% compared to head (0ae617e) 84.21%.

❗ Current head 0ae617e differs from pull request most recent head fe9e9c4. Consider uploading reports for the commit fe9e9c4 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #311      +/-   ##
==========================================
+ Coverage   81.25%   84.21%   +2.96%     
==========================================
  Files           4        4              
  Lines          32       38       +6     
  Branches        4        8       +4     
==========================================
+ Hits           26       32       +6     
  Misses          6        6              

Files Changed	Coverage Δ
src/components/LanguageSelector.jsx	100.00% <ø> (ø)
src/components/Footer.jsx	81.48% <100.00%> (+5.29%)	⬆️

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

[Cup0fCoffee]

👍

• I tested this
• I read through the code
• Includes documentation

[navinkarkera]

@mphilbrick211 This is ready for you.

[mphilbrick211]

Hi @openedx/fed-bom! Would someone be able to review/merge this for us? Thanks!

[arbrandes]

Just a quick note: @adamstankiewicz has brought it up that this seems to be partly orthogonal to what openedx/frontend-platform#440 is doing, so it warrants some additional discussion, particularly with regards to the styling mechanism. (The link URL manipulation is not as controversial, I would think.)

[adamstankiewicz]

Just a quick note: @adamstankiewicz has brought it up that this seems to be partly orthogonal to what openedx/frontend-platform#440 is doing, so it warrants some additional discussion, particularly with regards to the styling mechanism. (The link URL manipulation is not as controversial, I would think.)

On a closer look, it does appear this PR is getting at both branding customization (i.e., colors, spacing, etc.) and theming (a la comprehensive theming, customizing the functionality). What the above linked PR is doing is about ingesting Paragon's (compiled) CSS via MFE runtime config API whereas this PR is seemingly largely getting at the issue that the component, as implemented, is not flexible/customizable (e.g., to be able to override/extend the links used in the footer, etc.).

That said, the branding implications are probably separate from Paragon's design tokens / CSS variables given

I'm curious about other alternative approaches you've considered/tried and why they were less advantageous to your current approach. For example, could frontend-component-header expose a way to have similar customizations through its props API? For the more stylistic customizations, could frontend-component-footer instead define and use custom CSS variables that may be overridden by consumers in their MFE application styles. For instance, in your example, you're providing a backgroundImage via FOOTER_CUSTOM_STYLE. As an example alternative idea, you might manage this particular style change via CSS variables as opposed to configuration. For example, if frontend-component-header created/exposed a --openedx-footer-background CSS variable in the below pseudocode:

// frontend-component-footer
--openedx-footer-background: transparent;

.footer {
  background: var(--openedx-footer-background);
}

<footer className="footer d-flex border-top py-3 px-4">

// individual MFE
:root {
  --openedx-footer-background: url(https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTgb0Xw3iHTv4pobzu3cSStIU3txTxzC1LHNw&usqp=CAU);
}

I think a potential concern here is that it doesn't feel intuitive at first glance for engineers to modify frontend styles via a Python configuration setting. That said, it does help support writing that customization in 1 place and having it propagate to all MFEs whereas an expanded props API and/or using CSS variables may not mitigate that concern. That said, is it a safe assumption that all MFEs throughout Open edX would want these customizations, or would they still need to be defined on a MFE-by-MFE basis (fwiw, this latter concern won't be as much of an issue in a world with Domain MFEs via something like Piral given there should only be a single footer in the Domain MFE at any given time, rather than each individual MFE defining its own Footer).

I feel it'd be good to write down the context for these changes, their implications, and any alternatives considered as an Architectural Decision Record (ADR) in this repository as well.

[navinkarkera]

@arbrandes @adamstankiewicz Thanks for your inputs.

On a closer look, it does appear this PR is getting at both branding customization (i.e., colors, spacing, etc.) and theming (a la comprehensive theming, customizing the functionality). What the above linked PR is doing is about ingesting Paragon's (compiled) CSS via MFE runtime config API whereas this PR is seemingly largely getting at the issue that the component, as implemented, is not flexible/customizable (e.g., to be able to override/extend the links used in the footer, etc.).

@adamstankiewicz Yes, in simple terms, this PR allows adding/removing Paragon classes or raw css styling to some parts of footer, whereas the linked PR if I am not wrong, allows modifying those Paragon classes by overwriting them with its own version of compiled CSS.

I'm curious about other alternative approaches you've considered/tried and why they were less advantageous to your current approach. For example, could frontend-component-header expose a way to have similar customizations through its props API? For the more stylistic customizations, could frontend-component-footer instead define and use custom CSS variables that may be overridden by consumers in their MFE application styles.

So one of our clients wants to be able to host multiple microsites/tenants in a single OpenEdx instance and for each tenant/university they want to customize the footer. We managed to setup multsites using eduNexts eox-tenant which supports overriding django settings per tenant. Since MFE_CONFIG_API allows modifying MFE settings during runtime, we chose it over something like Branding API to add these configurations.

I think a potential concern here is that it doesn't feel intuitive at first glance for engineers to modify frontend styles via a Python configuration setting.

Agreed.

That said, it does help support writing that customization in 1 place and having it propagate to all MFEs whereas an expanded props API and/or using CSS variables may not mitigate that concern. That said, is it a safe assumption that all MFEs throughout Open edX would want these customizations, or would they still need to be defined on a MFE-by-MFE basis

We can still configure it separately for each MFE as MFE_CONFIG_API supports overriding configuration per MFE. Let me know if I misunderstood your comment here.

I feel it'd be good to write down the context for these changes, their implications, and any alternatives considered as an Architectural Decision Record (ADR) in this repository as well.

I can surely do that.

[abdullahwaheed]

@navinkarkera any updates on the ADR suggested by Adam

[Cup0fCoffee]

@abdullahwaheed Hi, @navinkarkera is on vacation until approximately end of August. We are discussing internally what we can do to compensate for that, and probably will take it over and write an ADR, however I can't confirm right now.

[dcoa]

This is an interesting approach and could be useful to make the platform more customizable in the MFE environment.

[dcoa]

I think this description should mention all the possible ways to modify the configuration, I mean, could include the JavaScript File https://github.com/openedx/frontend-platform/blob/master/docs/decisions/0007-javascript-file-configuration.rst

[Cup0fCoffee]

This wouldn't get internationalized.

[xitij2000]

AFAIK, the links in the branding API and translated, so if this PR is switched to using that API, the API should return appropriate results.

However, I don't think it's possible to do the same with the MFE config API. For that you'd need the API to return the translation context for each link and then provide a custom translation mapping. I think it's easier to handle this is edx-platform.

[Cup0fCoffee]

@abdullahwaheed FYI, I'm working on an ADR. The approximate timeline for it is end of this week, beginning of the next one.

[Cup0fCoffee]

@abdullahwaheed The ADR is ready for review - #326.

[mphilbrick211]

Hi @abdullahwaheed! Just checking in to see if you are able to review/merge this?

[navinkarkera]

Closing this PR as the ADR was not accepted.

[openedx-webhooks]

@navinkarkera 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.