Skip to content

feat: add course end dashboard plugin slots #1658

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

jansenk
Copy link
Contributor

@jansenk jansenk commented Mar 26, 2025

Add plugin slots to allow control of course end dashboard links

Copy link

codecov bot commented Mar 26, 2025

Codecov Report

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

Project coverage is 90.23%. Comparing base (e8d3bd7) to head (a936a87).

Files with missing lines Patch % Lines
src/index.jsx 0.00% 1 Missing ⚠️
...ginSlots/DashboardFootnoteLinkPluginSlot/index.tsx 94.73% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1658      +/-   ##
==========================================
+ Coverage   90.20%   90.23%   +0.02%     
==========================================
  Files         343      345       +2     
  Lines        5747     5774      +27     
  Branches     1341     1342       +1     
==========================================
+ Hits         5184     5210      +26     
- Misses        546      547       +1     
  Partials       17       17              

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


CourseExitViewCoursesPluginSlot.propTypes = {};

export default CourseExitViewCoursesPluginSlot;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't need to block this PR if you didn't know, but: whenever creating new files in this repo or any MFE repo, please:

  1. Use TypeScript .tsx instead of .jsx
  2. Use TypeScript types instead of propTypes - propTypes have been deprecated for 8 years!

You also don't need to use default exports anymore, but you can if you want to.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hey @bradenmacdonald thanks for the heads up. this PR fell by the wayside after the 2u shakeup.
I'm getting some CIreact/prop-types linting failures because of missing propTypes. I'm surprised that's the case. I tried to find some other PRs where someone makes this change, and I don't see anyone using any kind of /* eslint-disable react/prop-types */. Am I missing something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1632 is a good example. The check is green and there are no ignore directives. I'm not sure what I'm missing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't checked in detail, but it's likely that the linter is still requiring propTypes in .jsx files, but not in .tsx files. Could that be it? Because it's better to have propTypes than nothing, and you can't replace propTypes with types in a jsx file (unless you use JSDoc syntax but then you might as well convert to .tsx anyways)

Copy link
Contributor Author

@jansenk jansenk Apr 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed them to .tsx files. I'm not particularly familiar with the minutiae of typescript but it seems like I needed Params in both places in order for the linter to be okay with the change
const ComponentName: React.FC<Params> = ({ p1, p2, p3}: Params) => {
Not sure why both were needed, again, the linked PR seems to get by just using the angle bracket / java-style-parameterized-class syntax, but a green checkmark is a green checkmark

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah you should only need it in one or the other:

const ComponentName = ({ p1, p2, p3}: Params) => {

or

const ComponentName: React.FC<Params> = ({ p1, p2, p3}) => {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I guess there's no harm in specifying both.

@jansenk jansenk force-pushed the jkantor/course-end-plugins branch from c74ab08 to 11e68a0 Compare April 24, 2025 19:07
@jansenk jansenk enabled auto-merge (squash) April 25, 2025 13:48
@jansenk jansenk disabled auto-merge April 25, 2025 17:36
@jansenk jansenk force-pushed the jkantor/course-end-plugins branch from 9d0ac4f to a936a87 Compare April 25, 2025 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants