reduceMotion #334
reduceMotion #334
Conversation
| dispatchEvent: jest.fn(), | ||
| })), | ||
| }); | ||
| }); |
There was a problem hiding this comment.
Can you go ahead and add a test for the new option
There was a problem hiding this comment.
I don't have bandwidth at the moment, if anyone else does, please go for it.
src/countUp.ts
Outdated
| @@ -21,6 +21,7 @@ export interface CountUpOptions { // (default) | |||
| onCompleteCallback?: () => any; // gets called when animation completes | |||
| onStartCallback?: () => any; // gets called when animation starts | |||
| plugin?: CountUpPlugin; // for alternate animations | |||
| reduceMotion?: boolean | 'auto'; // 'auto' respects user preference | |||
There was a problem hiding this comment.
I think the property name is misleading, let's change to checkReducedMotionPref. The value should simply be a boolean, defaulting to true.
There was a problem hiding this comment.
How about respectPrefersReducedMotion?
(boolean, like you suggested, I dropped 'auto' option, now true is what 'auto' was)
|
Sure! On my phone right now, I can do that soon. The reason I did it the way I did: it will re-check as needed, so if someone lands on a site and decides there's too much motion, they can toggle the setting on their device, and see a change without reloading the website. Note that it isn't checking mid-animation. |
I'm submitting a...
Checklist
Description
Fixes #327.
Basic implementation of respecting user's preference for reduced motion.
I would mark this as "draft" if the option was presented, as it is missing test coverage.
Does this PR introduce a breaking change?
Sort of, but the default value of
this.options.reduceMotioncould be changed tofalse(rather than'auto'). Kinda think it's better to just break the expectation that this plugin will default to ignoring the user's preference for reduced motion....