-
-
Notifications
You must be signed in to change notification settings - Fork 32.8k
[ButtonBase] Convert to function component #15716
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
[ButtonBase] Convert to function component #15716
Conversation
|
@material-ui/core: parsed: -0.47% 😍, gzip: -0.15% 😍 Details of bundle changes.Comparing: a15f6ad...811e413
|
b51613b to
43ad125
Compare
43ad125 to
aae1e9e
Compare
| * no jsdom | ||
| */ | ||
| // eslint-disable-next-line camelcase | ||
| React.useLayoutEffect = function unstable_useIsomorphicLayoutEffect(fn, deps) { |
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.
Tried creating a separate ssr test suite but this was too much work for a couple of tests. While this isn't pretty it works.
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 have used process.env.NODE_ENV !== 'test' in NoSsr.js. I believe we should consolidate around one solution.
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.
But this will use useLayoutEffect in properly setup ssr test setups i.e. for test setups without JSDOm but with NODE_ENV=test this will trigger useLayoutEffect warnings
409f44f to
19c20f7
Compare
| describe('avoids multiple keydown presses', () => { | ||
| describe('event: keydown', () => { | ||
| // eslint-disable-next-line mocha/no-skipped-tests | ||
| describe.skip('avoids multiple keydown presses', () => { |
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.
The behavior is not apparent to me (due to no information in the test description).
It probably wants to avoid repeated keydowns causing a ripple but I'm not sure what the benefit is. If somebody presses and holds Space and then Enter another click will be dispatched at which point we probably should create a new Ripple. Not even including that only space triggers a ripple currently.
I would skip this for now and explore in a follow-up if we can get rid of the whole "avoid repeated keydown" logic.
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.
due to no information in the test description
I think that the test assertions and test actions should be what yield most of the information. The description is not really important.
Same as you, I don't understand what this test is about. Let's just kill it. It seems it was seeded in a 100% test coverage effort.
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 that the test assertions and test actions should be what yield most of the information
So in face of a cryptic test with a bad description you think tests have more information than descriptions? Why do you think these descriptions exist? Tests are an implementation detail. The description describes the API.
I'll keep it for now because I want to specifically fail it in a later PR: repeated keydown should ripple because you could press spacebar and then enter. Currently enter doesn't create a ripple but does fire a click.
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, the test description is the last thing I look at when working with the tests. The shorter & generic the descriptions can be, the better. It's less surface area for an outdated description. I'm not saying the description is useless, I'm saying that the test detail is more important. It's what we should most care about. it's our insurance, the more descriptive they are, the better.
Oh, you are right, Space triggers the ripple, but Enter doesn't. I agree that something seems off.
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.
outdated description
Descriptions rarely become outdated because that would mean you introduced a breaking change. This happens far less than a human reading a test.
| * no jsdom | ||
| */ | ||
| // eslint-disable-next-line camelcase | ||
| React.useLayoutEffect = function unstable_useIsomorphicLayoutEffect(fn, deps) { |
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 have used process.env.NODE_ENV !== 'test' in NoSsr.js. I believe we should consolidate around one solution.
| describe('avoids multiple keydown presses', () => { | ||
| describe('event: keydown', () => { | ||
| // eslint-disable-next-line mocha/no-skipped-tests | ||
| describe.skip('avoids multiple keydown presses', () => { |
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.
due to no information in the test description
I think that the test assertions and test actions should be what yield most of the information. The description is not really important.
Same as you, I don't understand what this test is about. Let's just kill it. It seems it was seeded in a 100% test coverage effort.
| useEnhancedEffect(() => { | ||
| ref.current = fn; | ||
| }); | ||
| return React.useCallback(event => (0, ref.current)(event), []); |
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.
| return React.useCallback(event => (0, ref.current)(event), []); | |
| return React.useCallback(event => ref.current(event), []); |
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.
https://stackoverflow.com/a/32275207/3406963
Also: The source uses comma operator.
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 didn't know that. It seems that in strict mode, the context is undefined. Does it have any practical implication?
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 don't have the full picture but I would trust Sophie to not post wrong code. Better stick with the source code instead of changing things we do not fully understand.
Co-Authored-By: Olivier Tassinari <[email protected]>
Makes it actually invariant once loaded
b22d7b8 to
811e413
Compare
| useEnhancedEffect(() => { | ||
| ref.current = fn; | ||
| }); | ||
| return React.useCallback(event => (0, ref.current)(event), []); |
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 didn't know that. It seems that in strict mode, the context is undefined. Does it have any practical implication?
| focusVisible: {}, | ||
| }; | ||
|
|
||
| const useEnhancedEffect = typeof window !== 'undefined' ? React.useLayoutEffect : React.useEffect; |
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.
You might have already answered this point, it's hard for me to follow the past discussions in the GitHub UI. I'm wondering if we can end up in a weird case where the event is triggered but the handled hasn't been updated yet.
Why not follow the pattern of the linked comment?
| const useEnhancedEffect = typeof window !== 'undefined' ? React.useLayoutEffect : React.useEffect; | |
| const useEnhancedEffect = React.useEffect; |
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 we can do that, we can probably remove unstable_useIsomorphicLayoutEffect too.
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.
GitHub seemed to have lost part of my answer when it duplicated the conversation.
We can't use useEffect because their priority might be lower than user input events. Which means you could call a stale value instead. This has to be done synchronous i.e. with useLayoutEffect
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.
Why not follow the pattern of the linked comment?
I don't understand. The linked comment is not using useEffect but useLayoutEffect. The rest is just the usual "trick react into thinking this is OK for ssr".
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.
OK, my bad
| describe('avoids multiple keydown presses', () => { | ||
| describe('event: keydown', () => { | ||
| // eslint-disable-next-line mocha/no-skipped-tests | ||
| describe.skip('avoids multiple keydown presses', () => { |
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, the test description is the last thing I look at when working with the tests. The shorter & generic the descriptions can be, the better. It's less surface area for an outdated description. I'm not saying the description is useless, I'm saying that the test detail is more important. It's what we should most care about. it's our insurance, the more descriptive they are, the better.
Oh, you are right, Space triggers the ripple, but Enter doesn't. I agree that something seems off.
|
Well done! |
Buttons playground
TODO:
Switching from testing implementation details via instance access to css classes. It's a bit better since these are coupled with the appearance but it's still questionable if unit tests are appropriate here. Fixtures and manual testing are probably more appropriate but lets see how this develops.
Future Work:
useFocusVisibleAPI (move state into hook; prepare in ref phase etc)Enterkey doesn't cause pulsate