Standardize plugin slots

[arbrandes]

Description

With this issue we're aiming to coordinate the following:

Standardize plugin slot name conventions

Every slot should adhere to the following conventions:

• It should be reasonably easy to deduce what a slot is used for from its slot ID
• Slot IDs should use snake case: footer_slot
• Slot IDs should end with _slot

Standardize how slots are exposed

Instead of inserting PluginSlots randomly throughout the code, they should each be implemented in their own subdirectory of plugin-slots, like so:

src/plugin-slots
├── SequenceContainerSlot
│   ├── index.jsx
└── UnitTitleSlot
    ├── index.jsx

The component name itself should be suffixed with Slot.

Add clear documentation

The main README should have a section dedicated to pointing users to the README in the src/plugin-slots directory, whin in turn should contain a list of all slots available in the MFE in question. Each slot entry should then link to the README for each individual slot implementation, as per the directory structure below:

src/plugin-slots
├── README.md
└── UnitTitleSlot
    ├── images
    │   └── post_unit_title.png
    ├── index.jsx
    └── README.md

An individual slot's README should:

• Explain what the slot's purpose is
• Give a simple example of a plugin that utilizes that slot
• Show, with screenshots, what the example plugin would look like on the page

Create slots as an example on every MFE supported by Tutor in Redwood

For each MFE supported by tutor-mfe, we'll give operators the option to use the Footer as a PluginSlot instead of forking frontend-component-footer.

To achieve this, we'll create a separate repository called frontend-slot-footer that provides a <FooterSlot /> implementation with <Footer /> from frontend-component-footer as its default content. Relevant MFEs will then be changed to depend on frontend-slot-footer instead of frontend-component-footer and replace all instances of <Footer /> with <FooterSlot />. This way, users that fork frontend-component-footer for customization will not need to take any action post-merge, while others that want to try out the new slot will be able to do so transparently.

Tasks

Beta Give feedback

1. fix: support frontend-platform 8.x as a peer dependency frontend-plugin-framework#60
   released +1
2. fix: remove header and footer dependencies frontend-plugin-framework#61
   released +1
3. feat: provide FooterSlot frontend-component-footer#423
   +0
4. fix!: remove FooterSlot component frontend-component-footer#427
   +0
5. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-account#1044
   +0
6. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-communications#201
   +0
7. fix: import FooterSlot from frontend-slot-footer package frontend-app-communications#202
   +0
8. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-discussions#698
   +0
9. feat: import FooterSlot from frontend-slot-footer package frontend-app-discussions#701
   +0
10. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-gradebook#391
    +0
11. feat!: organize plugin slots as components, add footer slot frontend-app-learning#1381
    +0
12. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-learner-dashboard#345
    +0
13. fix: update footer to resolve (not so) optional peer dependency issue frontend-app-profile#1022
    +0
14. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-profile#1017
    +0
15. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-ora-grading#331
    +0
16. feat: use frontend-plugin-framework to provide a FooterSlot frontend-template-application#799
    +0
17. Create ADR in the FPF repository to codify what was done here

Redwood backports

Beta Give feedback

1. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-account#1058
   +0
2. Footer slot backport frontend-app-communications#203
   +0
3. feat: import FooterSlot from frontend-slot-footer package frontend-app-discussions#714
   +0
4. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-gradebook#397
   +0
5. feat!: organize plugin slots as components, add footer slot (#1381) frontend-app-learning#1408
   +0
6. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-learner-dashboard#356
   +0
7. Footer slot backport frontend-app-profile#1030
   +0
8. feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-ora-grading#332
   +0

[brian-smith-tcril]

Footer Slots:

• Authn (no footer)
• Account feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-account#1044 fix: import FooterSlot from frontend-slot-footer package frontend-app-account#1048 fix: use frontend-slot-footer that supports all footer versions frontend-app-account#1050
• Communications feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-communications#201 fix: import FooterSlot from frontend-slot-footer package frontend-app-communications#202
• Course Authoring (Studio Footer)
• Discussions feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-discussions#698 feat: import FooterSlot from frontend-slot-footer package frontend-app-discussions#701
• Gradebook feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-gradebook#391
• Learner Dashboard feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-learner-dashboard#345
• Learning feat!: organize plugin slots as components, add footer slot frontend-app-learning#1381
• ORA Grading feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-ora-grading#331
• Profile feat: use frontend-plugin-framework to provide a FooterSlot frontend-app-profile#1017

Other Slots:

• Create components for PluginSlots, standardize id naming frontend-app-learner-dashboard#344

[arbrandes]

We re-examined our stance on asking users that fork frontend-component-footer to take action after this work lands, and are going instead with an approach that takes that customization path into account. From the updated description:

For each MFE supported by tutor-mfe, we'll give operators the option to use the Footer as a PluginSlot instead of forking frontend-component-footer.

To achieve this, we'll create a separate repository called frontend-slot-footer that provides a <FooterSlot /> implementation with <Footer /> from frontend-component-footer as its default content. Relevant MFEs will then be changed to depend on frontend-slot-footer instead of frontend-component-footer and replace all instances of <Footer /> with <FooterSlot />. This way, users that fork frontend-component-footer for customization will not need to take any action post-merge, while others that want to try out the new slot will be able to do so transparently.

[davidjoy]

Would it make sense to just put FooterSlot in the existing footer repository, or in frontend-platform to avoid needing another repository? (I haven't thought this through completely, but figure you have)

[brian-smith-tcril]

Would it make sense to just put FooterSlot in the existing footer repository

We tried this first, but ran into issues. The options to make this possible would either be:

• Make it so the exported Footer component includes the FooterSlot
  • This felt less than ideal from a semantic perspective. It isn't clear as a consumer if you have the slot or not.
• Export the FooterSlot component as a named export
  • This is what we tried at first, it was a problem for people that use forked footers because their forks didn't export that component, so the MFEs were expecting something the fork didn't provide.

or in frontend-platform

Hadn't considered that.