feat: Added PluginSlot to wrap IDVerificationPage component

[rijuma]

Description

This wraps the IDVerificationPage with a PluginSlot component to allow experiment with a new IDV flow.
Similar implementations can be seen in frontend-app-learner-dashboard for example.

Added a lint:fix script as well for practical reasons.

How Has This Been Tested?

Tested on local environment and the default behavior is shown as expected.

Merge Checklist

• Is there adequate test coverage for your changes?

Post-merge Checklist

• Deploy the changes to prod after verifying on stage or ask @openedx/edx-infinity to do it.
• 🎉 🙌 Celebrate! Thanks for your contribution.

[codecov]

Codecov Report

Attention: Patch coverage is 75.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 58.61%. Comparing base (17ce32b) to head (dcdd024).
Report is 9 commits behind head on master.

Files	Patch %	Lines
src/plugin-slots/IdVerificationPageSlot/index.jsx	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1097      +/-   ##
==========================================
+ Coverage   58.55%   58.61%   +0.05%     
==========================================
  Files         115      117       +2     
  Lines        2309     2317       +8     
  Branches      638      641       +3     
==========================================
+ Hits         1352     1358       +6     
- Misses        896      898       +2     
  Partials       61       61              

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

[schenedx]

See my inline comment.

[schenedx]

With a change like this, if we deploy this to production, the existing IDV flow will be gone.
I think we need a period of this code where the plugin slot and the existing IDV flow co-exist for a while. This way, while we build out the plugin slot, the existing IDV flow still serves our learners.
Then we need a waffle flag to do the switch from the entry link, which is probably 3 different places.

[MichaelRoytman]

Whatever component is wrapped by the PluginSlot (i.e. IdVerificationPage) is the "default component" and will be rendered by default if there is no plugin configuration specified (e.g. in an env.config.[js|jsx] file in edx-internal) or no overriding plugin in the said plugin configuration, so this deployment strategy isn't necessary. If we merge this as-is, there will be no changes to the IDV page in the learning MFE for 2U or any other deployments. There are more details the frontend-plugin-framework docs. Does that assuage your concerns?

[rijuma]

Indeed. I tested it locally but with no configuration and the <IdVerificationPage> is rendered by default.

[schenedx]

Nice. I didn't know plugin slot handles this the way it should be. Thank you for pointing it out.

[MichaelRoytman]

This looks good to me. I know you wanted to discuss more today, so I've held off on approving for now.

Also, should/can we test the use of the PluginSlot on the page?

[MichaelRoytman]

Whatever component is wrapped by the PluginSlot (i.e. IdVerificationPage) is the "default component" and will be rendered by default if there is no plugin configuration specified (e.g. in an env.config.[js|jsx] file in edx-internal) or no overriding plugin in the said plugin configuration, so this deployment strategy isn't necessary. If we merge this as-is, there will be no changes to the IDV page in the learning MFE for 2U or any other deployments. There are more details the frontend-plugin-framework docs. Does that assuage your concerns?

[MichaelRoytman]

Is it necessary to write a test for the application to ensure that the PluginSlot is rendered (e.g something like this)?

[schenedx]

👍

[rijuma]

Is it necessary to write a test for the application to ensure that the PluginSlot is rendered (e.g something like this)?

We discussed this offline and we came to the conclusion that adding a test for the index file would be complicated enough to consider it out of scope for this small update.

[MaxFrank13]

Hello 👋 I just have one recommendation/request to document the plugin slot using this format in the MFE. You can use frontend-app-learning for reference as well — PluginSlots documentation & PluginSlot being implemented.

This may require you to modify your implementation a bit but it is the way that the open source community has decided PluginSlots should be accounted for. We are still catching up on this with some other PluginSlot implementations in the org (ie. Learner Dashboard), but for new ones, it'd be nice to document them from the start.

[jsnwesson]

Hey all! Agreeing with Max that it would be nice to have a place where all PluginSlots live. You can reference the Learning MFE to see how they organize three PluginSlots. This will also make testing a PluginSlot much easier, I think.