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.

[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.

🔘 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.

🔘 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

🔘 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

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.87%. Comparing base (e556d5b) to head (06aa67f).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1645      +/-   ##
==========================================
+ Coverage   90.83%   90.87%   +0.03%     
==========================================
  Files         344      347       +3     
  Lines        5794     5816      +22     
  Branches     1374     1373       -1     
==========================================
+ Hits         5263     5285      +22     
  Misses        512      512              
  Partials       19       19              

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 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.

[bradenmacdonald]

@xitij2000 This looks good to me, though @farhaanbukhsh is the maintainer now and @arbrandes knows more about plugin slots and the future direction of this MFE. Do either of you guys want to look at this or approve it for us?

[bradenmacdonald]

Can the example use CourseTabLink or is that not part of the plugin API?

[xitij2000]

That was a last minute refactoring so forgot to update the docs. It makes sense to have that here. Will update.