feat: Add slots to add tab links and add mechanism for plugin routes

[xitij2000]

Description

This PR adds mechanisms to add course tabs using a frontend plugin.

It includes two plugin slots:

• course_tab_links_slot: This slot allows adding additional course tabs or modifying existing course tabs.
• course_page_route_slot: This slot allows create a full new page in the learning MFE.

It also adds a new mechanism to add course routes using the PLUGIN_ROUTES config. This is a simple array that adds new routes for the MFE that can then be handled by plugins.

The combination of the above will allow injecting a new course tab by:

• Adding a new route to the PLUGIN_ROUTES array.
• Adding a slot to the course page route slot so that the page is rendered on that route
• Adding a new link to the course_tab_links_slot.

It is also possible to add the links anywhere else, to simply add new pages that are not tabs.

Other Information

Currently there is a single plugin slot for all pages and each plugin would need to check if the route matches and render itself. Another alternative is for the plugin routes to be a mapping of plugin name to the route, and the plugin name can be added to the slot ID. For example:

PLUGIN_ROUTES = {
  tab1: "/course/:courseId/tab1",
  tab2: "/course/:courseId/tab2",
};

<PluginSlot id={`${pluginName}_page_route_slot`} ... />

This would create slots like: tab1_page_route_slot and tab2_page_route_slot etc.

Or, it can just use the route itself in the slot name. While this will result in clumsy names like: "/course/:courseId/tab1_page_route_slot" there is not reason why that shouldn't work.

[openedx-webhooks]

Thanks for the pull request, @xitij2000!

This repository is currently maintained by @openedx/committers-frontend-app-learning.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

:radio_button: Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

:radio_button: Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

:radio_button: Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

:bulb: As a result it may take up to several weeks or months to complete a review and merge your PR.

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 90.86%. Comparing base (7233f08) to head (a515991). :warning: Report is 6 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1645      +/-   ##
==========================================
+ Coverage   90.83%   90.86%   +0.03%     
==========================================
  Files         344      348       +4     
  Lines        5794     5814      +20     
  Branches     1333     1382      +49     
==========================================
+ Hits         5263     5283      +20     
+ Misses        514      512       -2     
- Partials       17       19       +2     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[xitij2000]

@bradenmacdonald Would love to get your thoughts on the approach used in this PR. It's doing a few non-standard things.

We wanted to add a new course tab, for which we need two things.

1. We need some way to add an actual tab. This is a straightforward slot.
2. We need some place for the tab to link to.

To add a new page that feels like part of the platform we need some way to extend the routes to allow creating a new page. I tried making the routes pluggable, but the router refuses to work with components that aren't a Route. Which led to the approach used here, which is to add a config value for defining new routes, each route gets its own slot so you can create a new page there.

[bradenmacdonald]

@xitij2000 I don't think plugins can add <Route> objects directly, because as you said, the Router won't accept any children that aren't <Route>. But I think what you can do is add a catch-all route going to an empty page that has a plugin slot and on that page, each plugin can add a <Routes><Route ... /></Routes> entry as a separate slot, and that will work fine.

This is because:

• <Routes> can appear anywhere within the page hierarchy
• Multiple <Routes> can even appear on the same page

See https://github.com/openedx/frontend-app-authoring/blob/aeefcc639f430c4769b0903cad0da7977cb40cf3/src/pages-and-resources/PagesAndResources.jsx#L88-L93 for an example of this. It's not wrapped in a plugin slot, but it would work just the same way if it were.

Also, I think we want to move away from a very config-heavy plugin approach toward something where plugins "register themselves" and require minimal config other than installation, so I think this sort of approach (adding <Routes> to an empty slot) is better long-term.

[itsjeyd]

Hey @xitij2000, are you still planning to continue working on this PR?

[xitij2000]

@itsjeyd I'm looking into the budget situation for this, will update once that is clear.

[xitij2000]

@bradenmacdonald I've switched to the mechanism you recommended. One issue is that now I can no longer have a route like /course/:courseId/xyz but other than that it seems to work well.

[bradenmacdonald]

@xitij2000 Sorry for the slow reply. If the slot is named "Course Page Slot" then maybe you should mount the slot as a catch-all for /course/:courseId/*, and then plugins could add new routes like /course/:courseId/xyz. They couldn't add new routes like /somethingelse/:courseId/, but that's fine - I think the former is more consistent with the idea of a "course page slot" than the latter, and you could even add a separate "Learning Page Slot" for adding routes to / that aren't nested under existing paths.

[xitij2000]

@xitij2000 Sorry for the slow reply. If the slot is named "Course Page Slot" then maybe you should mount the slot as a catch-all for /course/:courseId/*, and then plugins could add new routes like /course/:courseId/xyz. They couldn't add new routes like /somethingelse/:courseId/, but that's fine - I think the former is more consistent with the idea of a "course page slot" than the latter, and you could even add a separate "Learning Page Slot" for adding routes to / that aren't nested under existing paths.

I tried this and unfortunately it is simply not working. It keeps getting redirected to the home page. I think this is because there is already a match for /course/:courseId/:sequenceId which is also catchall. The only way out I think would be to have /course/:courseId/plugin/* or similar (i..e use p instead of plugin or c or some other separator like _).

[bradenmacdonald]

@xitij2000 Ah, I see. Well thanks for trying. What do you think makes the most sense then? I kinda like the idea of having a a slot under /course/:courseId/plugin/* as you're suggesting.

Though maybe we should also ask @arbrandes if there's a more official way for plugins to add new URLs, especially in frontend-base world.

[xitij2000]

@xitij2000 Ah, I see. Well thanks for trying. What do you think makes the most sense then? I kinda like the idea of having a a slot under /course/:courseId/plugin/* as you're suggesting.

Though maybe we should also ask @arbrandes if there's a more official way for plugins to add new URLs, especially in frontend-base world.

That is a good point. I think there is a better way with frontend-base which AFAIK would work across all MFEs. From what I remember with frontend-base you can simply extend the list of routes via frontend-template-site. So at that point of time this work might not be needed at all.

Is my understandin correct @arbrandes? If so we can pause this work and just temporarily maintain the drift on the client side till the better approach from frontend-base is implemented.

[arbrandes]

@xitij2000,

you can simply extend the list of routes via frontend-template-site

That is correct. Any plugin (any "app") will be able to easily extend routes. You can see how it works in the "slot showcase" plugin/app (usable by running npm run dev in frontend-base).

[xitij2000]

@arbrandes Thanks for clarifying!

@bradenmacdonald I think given the above it might make sense to refactor this PR to only contain the changes relevant to adding a new tab and remove the code related to custom routes since that approach will change with the move to frontend-base. For now we can keep this bit of code drift in the client branch.

CC: @pkulkark

[bradenmacdonald]

@xitij2000 OK, makes sense.

[xitij2000]

@bradenmacdonald I've removed all the routes-related code.

[itsjeyd]

Hey @farhaanbukhsh and @arbrandes, a friendly reminder to check out this PR. Braden already reviewed it, so a quick look from one of you would probably be enough to get it over the line.

[xitij2000]

@farhaanbukhsh I've addressed the points you raised. Do have a look and merge if it feel ready.