-
Notifications
You must be signed in to change notification settings - Fork 12
WB Date Picker: initial migration #2876
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
base: feature/datepicker
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 4dbb09e The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Size Change: +4.86 kB (+4.46%) Total Size: 114 kB
ℹ️ View Unchanged
|
A new build was pushed to Chromatic! 🚀https://5e1bf4b385e3fb0020b7073c-fpqbiczclm.chromatic.com/ Chromatic results:
|
GeraldRequired Reviewers
Don't want to be involved in this pull request? Comment |
Addresses WB-2016
__docs__/wonder-blocks-date-picker/date-picker-input.stories.tsx
Outdated
Show resolved
Hide resolved
beaesguerra
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exciting we're bringing the date picker to WB! Doing a first pass and left some questions! I haven't reviewed the UI components too deeply yet since a lot of it is moved over from frontend (let me know though if there are specific areas to pay more attention to!). I also haven't done some manual testing yet!
| const extensions = [".js", ".jsx", ".ts", ".tsx"]; | ||
|
|
||
| return { | ||
| external: (id) => id.endsWith(".css"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not too familiar with rollup so I was curious about this! I asked an LLM and it said: This tells Rollup: "Don't bundle CSS files into the output."
We don't currently include css from third parties in WB, so I'm wondering how that css will get consumed in frontend
I'm also curious about how it would fit in with the upcoming CSS modules work (cc: @jandrade in case he has thoughts on this!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There might be a better way to do this, but the purpose was to get the date picker package to build. It was breaking on the CSS import for customization.
| moduleNameMapper: { | ||
| "^@khanacademy/wonder-blocks-(.*)$": | ||
| "<rootDir>/packages/wonder-blocks-$1/src/index.ts", | ||
| "\\.(css|less|scss|sass)$": "<rootDir>/config/jest/css.mock.js", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would consumers also need to set this up for things that use the date picker? I think maybe no since perseus and frontend uses css files already (?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume because frontend already has this setup and it doesn't break testing or bundling, it should be fine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might not be applicable for consumers anymore because the CSS is bundled. But it was definitely needed for our tests!
| "react-day-picker": "catalog:", | ||
| "temporal-polyfill": "catalog:" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these be dependencies at the wonder-blocks-date-picker package level, rather than root?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point...maybe BirthdayPicker and DatePicker could each handle them instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually we do need these dependencies at the root, or our stories fail!
| MaybeNativeDatePicker, | ||
| DatePickerOverlay, | ||
| DatePickerInput, | ||
| DatePicker, | ||
| TemporalLocaleUtils, | ||
| type CustomModifiers, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there some exports that could be internal to WB only and don't need to be exported? For example, I see only the DatePicker uses the DatePickerOverlay component in frontend, so we could choose not to export it!
Less exports would mean less external facing APIs to maintain and we have more flexibility with internal breaking changes!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can get rid of DatePickerOverlay and its stories, which required the import. That one will be replaced by WB Floating and isn't really serving a purpose!
I'm not so sure about TemporalLocaleUtils and CustomModifiers, though. I started to move the locale utils into wonder-blocks-core before realizing it imports CustomModifiers, which imports a type from react-day-picker. So I think I'll opt to leave them be for now.
| * Utility functions for working with Temporal dates in react-day-picker. | ||
| * These replace the MomentLocaleUtils that were previously used. | ||
| * | ||
| * Question: Should we move this to a separate package? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea 💡 I think it would be useful to have date utilities, probably in a different package so consumers can use the date utilities without needing a dep on react-day-picker!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a comment elsewhere in the PR discussion, but the CustomModifiers complicates things with an import from react-day-picker. That wrinkle makes me think it should live here.
| import calendarIcon from "@phosphor-icons/core/bold/calendar-blank-bold.svg"; | ||
| import type {CustomModifiers} from "../util/types"; | ||
|
|
||
| interface Props { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious if the DatePickerInput should also had a readonly state, similar to other form field components!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh yes, probably! I will file an issue for a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the readonly issue: https://khanacademy.atlassian.net/browse/WB-2172
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to use wb css variables for the line height and font size values?
|
|
||
| const validateAndUpdate = React.useCallback( | ||
| (newDate?: Temporal.PlainDate | null) => { | ||
| // TODO: do we need to allow other locales/formats? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would think we'd need to account for the locale!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, that will be part of this ticket! https://khanacademy.atlassian.net/browse/FEI-7342
| ) { | ||
| /* eslint-disable-next-line no-alert | ||
| -- | ||
| We really should have a different UX for this but this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can use LabeledField for displaying error messages!
packages/wonder-blocks-date-picker/src/components/maybe-native-date-picker-display.tsx
Outdated
Show resolved
Hide resolved
| }, | ||
| "references": [ | ||
| {"path": "../packages/wonder-blocks-accordion/tsconfig-build.json"}, | ||
| {"path": "../packages/wonder-blocks-birthday-picker/tsconfig-build.json"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These packages were missing before, so I added them while I was in there.
| @@ -0,0 +1,6 @@ | |||
| *.tsbuildinfo | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This too -- Card had missed some of the boilerplate files other packages have.
build-settings/rollup.config.mjs
Outdated
| ], | ||
| input: `packages/${pkgName}/src/index.ts`, | ||
| plugins: [ | ||
| postcss({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the logic to bundle the CSS, so consumers won't have to deal with it too! I verified we need the CSS import from react-day-picker to get a properly styled calendar, but the custom @layer styles were outdated so I removed them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would affect all the other packages, so I'm not sure if there is another approach we could take for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it did break the the pnpm run dev script too. I restored the logic I had originally and added docs on how to include the stylesheet as a consumer!
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## feature/datepicker #2876 +/- ##
==========================================
==========================================
Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
jandrade
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this! I left multiple comments to simplify this PR and keep only the things we need for now. I think that after determining if we want/need to include the native input, then we should add that in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: I don't think we need to expose the package internals as we only expect devs to use DatePicker directly. These stories can be removed. Same with DatePickerOverlay and probably with MaybeNativeDatePicker (still TBD).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. I removed them!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: As mentioned in other stories, I'm not sure if we are going to use this approach, or if we are going to use the picker directly in all devices. We should talk about this offline. For now, I think it's fine not to include this in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, I stored it in a branch to potentially revisit later!
build-settings/rollup.config.mjs
Outdated
| ], | ||
| input: `packages/${pkgName}/src/index.ts`, | ||
| plugins: [ | ||
| postcss({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would affect all the other packages, so I'm not sure if there is another approach we could take for this.
build-settings/rollup.config.mjs
Outdated
| plugins: [ | ||
| postcss({ | ||
| // Extract CSS to a separate file | ||
| extract: path.resolve(`packages/${pkgName}/dist/index.css`), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmmm this might conflict with the CSS variables build setup (specially the wb-tokens package). Did you find any issues with the build? specially when used in frontend?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, so I changed it back to not bundle together!
| "react-router": "catalog:", | ||
| "react-router-dom": "catalog:", | ||
| "react-router-dom-v5-compat": "catalog:", | ||
| "react-window": "catalog:", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: I don't think these deps are required by this package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought: As mentioned before, we might not need this logic anymore as we could end up using DatePicker directly. My hesitation about including this in the codebase is that we should experiment first if we are going to keep this approach or if we are going to allow using DatePicker directly (my initial inclination is the latter).
Depending on the approach we choose, it feels safer to just include DatePicker in this PR, then later include the rest of the implementation if we decide to include this Maybe.. wrapper.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: As the file comment says, DatePicker was unusable on iOS, but this was tested years ago. With v9, we might not need to use this wrapper anymore.
| DatePickerInput, | ||
| DatePicker, | ||
| TemporalLocaleUtils, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: we should probably only expose DatePicker and TemporalLocaleUtils if these are going to be needed by consumers.
Summary:
This PR migrates the Date Picker from frontend to Wonder Blocks. Upgrades react-day-picker, removes Moment in favor of Temporal (with polyfill).
Addresses WB-1112, WB-1099, WB-1220, WB-2016
Issue: WB-1112
Not included:
momentlocales toreact-day-picker/date-fnswindow.alertfor validation errorsTest plan:
/?path=/docs/packages-date-picker-datepicker--docs