[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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
| return React.useCallback(event => (0, ref.current)(event), []); | |
| return React.useCallback(event => ref.current(event), []); |
There was a problem hiding this comment.
https://stackoverflow.com/a/32275207/3406963
Also: The source uses comma operator.
There was a problem hiding this comment.
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.
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.
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.
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.
I we can do that, we can probably remove unstable_useIsomorphicLayoutEffect too.
There was a problem hiding this comment.
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.
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".
| 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.
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