Allow Runtime Configuration

[Jacatove]

Description

This PR is part of the work to make it possible to configure the frontend applications at runtime (you can refer to this openedx/wg-frontend#103).

Changes

• Update frontend-platform to version 2.5.0.
• Update the footer and header to avoid peer dependency errors.
• Create a component Head, that uses Helmet library and integrates internationalization to change the MFE name in the title tag according to the language, and change the favicon in runtime.
• Add react-helmet, enzyme and enzyme-adapter-react-16.

Screenshot

In progress

How to test

To allow runtime configuration set a new environment variables MFE_CONFIG_API_URL and APP_ID in the env file and add the api url ( To test this you can use the API from this 

https://github.com/openedx/edx-platform/pull/30473 or use an external tool to mock the API response).
The API should respond with a JSON with the config values, something like:

{
"SITE_NAME": "Test Site",
"LOGO_URL": "https://testimage.com/logo.svg",
"LOGO_TRADEMARK_URL": "https://testimage.com/logo.svg",
"LOGO_WHITE_URL": "https://testimage.com/logo.svg",
"FAVICON_URL": "https://testimage.com/favicon.ico",
}

The initialize process should work normally.
**Note:** You can combine buildtime and runtime configuration

[dcoa]

Evidence, any mayor change.

[codecov]

Codecov Report

Base: 69.20% // Head: 69.64% // Increases project coverage by +0.43% 🎉

Coverage data is based on head (6e46f16) compared to base (da03b19).
Patch coverage: 57.14% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #104      +/-   ##
==========================================
+ Coverage   69.20%   69.64%   +0.43%     
==========================================
  Files          14       16       +2     
  Lines         276      280       +4     
  Branches       63       63              
==========================================
+ Hits          191      195       +4     
  Misses         85       85              

Impacted Files	Coverage Δ
src/index.jsx	0.00% <0.00%> (ø)
src/components/Head/Head.jsx	100.00% <100.00%> (ø)
src/components/Head/messages.js	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[cdeery]

According to this blog https://www.freecodecamp.org/news/react-helmet-examples/ react-helmet is considered deprecated, and react-helmet-async https://github.com/staylor/react-helmet-async is the new version. Do you have any more information about this?

[dcoa]

Thanks, @cdeery for your review

The main reason to decided to use react-helmet was other apps like frontend-app-learning were using it. https://github.com/openedx/frontend-app-learning/blame/master/package.json#L54

I am not able to find more information about an officially deprecated announcement, but that seems to be deprecated according to nfl/react-helmet#689 (in addition the last commit date was 2020) and at the same time is still used for the community check date of this issue nfl/react-helmet#693

We could make the change of the library to react-helmet-async

And @arbrandes this could be something to consider for the FWG, due to different apps are using this library (don´t seem to be a problem with the actual environment but maybe new versions of react don't support it).

[arbrandes]

Yes, this looks like a concern for more repos than just this one.

It doesn't excuse us from doing the right thing, of course. @cdeery, would an issue to tackle this across the board be enough to otherwise merge this as is? This is something @abdullahwaheed and FED-BOM could probably help us with.

[dcoa]

I check how react-helmet-async could be used, for this specific case I think a new context is too much for the purpose of this change then I use another implementation explained in the official repo.

I create a commit to put this into consideration and find the best way to make the change to the library. :)

[cdeery]

Thanks @dcoa for making this change. I think this is much better. I understand that other teams are using the older version, but this helps with not creating tech debt.
This generally looks ok to me. I am not sure what you mean by using a context is "too much", I would be surprised if it added a noticeable burden to the app. My inclination would be to use the library as indicated as the common pattern, because it looks like it would avoid any bugs that might occur if the explicit argument passing is missed.

[dcoa]

@cdeery I made the changes to use HelmetProvider, let me know what you think. :)

[openedx-webhooks]

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

[cdeery]

I'm sorry, but I'm confused by this. If the HelmetProvider is a context, then I would expect it to wrap everything that might modify the head.

<AppProvider>
  <HelmetProvider context={helmetContext}>
     <Head />
     <Header/>
     ... everything else...
  </HelmetProvider>
</AppProvider>

That way, anything that accesses the header is in the context of the provider.

And then the Head implementation contains a Helmet instance that wraps the header metadata.

Am I misunderstanding?

[dcoa]

In this case, other components can't modify the favicon and title tag, because the values come directly from the config (comes from AppProvider), that's why I don't think the provider has to wrap all the components inside the app.

Let me know if that makes sense either I'm okay to make the change.

[cdeery]

Ah. I see. I think that it would be best to still use the pattern where the app is wrapped for a couple of reasons, but I can see where they don't seem related to the problem you are solving:

1. This is the first use of react-helmet-async, and will end up being copy and pasted into other projects as an example. Other projects may use it for other reasons.
2. If the use of it is expanded in the future for header metadata that might be modified by the application, having the context wrapping it will make those changed "just work", eliminating bugs and debugging.

If you're ok to make the change, I would really appreciate it. Thanks.

[dcoa]

I made the change, could you take a look, please? @cdeery

[cdeery]

Great. Thank you for making the changes. This looks good.

[openedx-webhooks]

@Jacatove 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future.