feat: Introduce slot for customizing course tab navigation#1917
feat: Introduce slot for customizing course tab navigation#1917xitij2000 wants to merge 1 commit into
Conversation
|
Thanks for the pull request, @xitij2000! This repository is currently maintained by 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 approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo 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:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere 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: 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:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
Adds a new plugin slot (`CourseTabsNavigationSlot`) to enable customization, modification, or hiding of the course tab navigation. Updated relevant components to integrate with the new slot.
d1f2907 to
c9693eb
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1917 +/- ##
==========================================
+ Coverage 91.30% 91.32% +0.02%
==========================================
Files 344 346 +2
Lines 5774 5790 +16
Branches 1351 1387 +36
==========================================
+ Hits 5272 5288 +16
Misses 483 483
Partials 19 19 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
brian-smith-tcril
left a comment
There was a problem hiding this comment.
Overall this looks great! I left a couple comments about the PropTypes -> .tsx conversion, once those are addressed this should be good to land!
|
|
||
| interface LoadedTabPageProps { | ||
| activeTabSlug: string; | ||
| children: React.ReactNode; |
There was a problem hiding this comment.
| children: React.ReactNode; | |
| children?: React.ReactNode; |
functionally equivalent to not having the ? but this better communicates it as optional (matching what we had with PropTypes
| activeTabSlug: string; | ||
| children: React.ReactNode; | ||
| courseId: string; | ||
| metadataModel: string; |
There was a problem hiding this comment.
| metadataModel: string; | |
| metadataModel?: string; |
The PropTypes version of this was optional
There was a problem hiding this comment.
Wherever possible I tried to go for a more strict definition that would still work. Here the consumer StreakModal marks it as required. Since it gets a default value, I think the only situation where it would be undefined would be if someone explicitly passes undefined.
There was a problem hiding this comment.
After digging into this a bit I agree a more strict definition works. StreakModal having it marked as required doesn't really play into this, as it would get the required string from LoadedTabPage's default. TabPage, on the other hand, is the only consumer of LoadedTabPage and has metadataModel set up to be required.
With that in mind, I think it makes sense to:
- Make the switch to required from optional
- Drop the default (it's unreachable when
metadataModelis required) - Update any tests that rely on the default
| children: React.ReactNode; | ||
| courseId: string; | ||
| metadataModel: string; | ||
| unitId: string | null; |
There was a problem hiding this comment.
| unitId: string | null; | |
| unitId?: string | null; |
To match the PropTypes logic we:
?so it's optionalstringfor the actual string type| nullbecause?just supportsundefined, notnull
We likely don't need to match the PropTypes logic exactly here, and ideally we could just use unitId?: string and default to undefined, but that'd require some deeper digging (and should probably be a follow-up issue).
From a sub-components perspective, we can just check where unitId is used to see if defaulting to undefined would be a reasonable option. It seems to only be in InstructorToolbar, and it like undefined would be fine there:
The consumers of LoadedTabPage are where it gets messy. Org search shows it only being used in frontend-app-learning which limits the blast radius a bit, but there's still a lot of null being used. In TabPage for example:
and then we'd need to dig into the consumers of TabPage and so on.
|
|
||
| return ( | ||
| <div id="courseTabsNavigation" className={classNames('course-tabs-navigation', className)}> | ||
| <div id="courseTabsNavigation" className="mb-3 course-tabs-navigation"> |
There was a problem hiding this comment.
At first I was slightly concerned about this moving in here instead of coming from the consumer in LoadedTabPage, but it seems the only other place that references this is
which is only used by the next line
which only cares about the top which isn't changed by mb.
Adds a new plugin slot (
CourseTabsNavigationSlot) to enable customization, modification, or hiding of the course tab navigation.