-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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] Fix when changing enableRipple prop from false to true #19667
Merged
oliviertassinari
merged 13 commits into
mui:master
from
dmtrKovalenko:bugfix/crash-button-on-missing-ref
Feb 26, 2020
Merged
Changes from all commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
f546941
Fix crashing if rippleRef is null
dmtrKovalenko c9e7761
Add test that reproduces crash
dmtrKovalenko 285a7df
Fix crashing by moving <NoSsr /> outside of rendering conditino
dmtrKovalenko d17f1a1
Get rid of autoFocus button in tests
dmtrKovalenko fefc0af
Ignore typescript errors in test
dmtrKovalenko 95a3237
Run prettier in ButtonBase.test.js
dmtrKovalenko 07a312f
Get rid of @ts-ignore
dmtrKovalenko 85a4ae5
Fix syntax error in typescript type comment alias
dmtrKovalenko f646dbb
Throw error if buttonRef is missing in test
dmtrKovalenko 9ae49af
Allow chilren={null} in <NoSsr />
dmtrKovalenko d63a6ad
yarn prettier
oliviertassinari 9f2921b
yarn docs:api
oliviertassinari 1f124be
let's not forget about the TypeScript types
oliviertassinari File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 is the type of defensive checks I was working about that TypeScript encourage and that might hide root issues. @eps1lon what do you think?
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 one is not hiding issue of test, you can check it and without changes this test will still crash
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.
Agree, I was wondering about the pattern in general, what should be our "baseline" (default approach) for this concern :)
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.
Do we even need this check here? What happens if
App
mounts but the ref isn't instantiated?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 check is for typescript compiler, to get rid of
@ts-ignore
. Actually it is impossible inside theuseEffect
(maybe only if somebody will specifically delete dom element after react commit phase and before effects are run?)Right here it is not needed, but I am sure that in the code we have to guard the refs, even if it is hide bugs (IMHO such guards can't hide bugs, because e.g. in this particular issue element will not gain ripple focus if check was done - it is a bug as well, but no so critical as crash)
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.
So we agree that it shouldn't be guarded against. There was a defect in the code which we wouldn't have been able to detect with a defensive check.
As long as typescript is only a type checker + transpiler I don't care about
@ts-ignore
in JSX. TypeScript is particularly bad with React. If it complains, we disable it. Just like with false positives in lint rules.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.
We still need to get rid of this check in the test or handle the else case.
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 I will add throwing error in the else branch.
Cannot agree — we would be able. If there will be a guard, when enableRipple changes we simply not starting rippleEffect. It is an issue as well that can be noticed and fixed in the same way as current one.
But if some user will notice crash in the most basic
Button
component — it will spoil the trust to material-ui as qualified and reliable tool.I have strong opinion that if something can crash — you must not let it crash. Even if you will use more reliable type system like ReasonML — it will complain about refs, because we cannot trust DOM, like we cannot trust users and we cannot trust developers who uses our components.
I can propose you the following api for using in the core components.
Which will assert ref is not null and if it’s missing warn user and ask to raise an issue. Thus our component will even look more clever :)
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.
As far as I understand the issue, this is an internal consideration. Regarding the impact userland, I think that a fast feedback loop should be preferred.
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.
@dmtrKovalenko I love the new throw error in the branch, it's a great edge in case the action prop stop working as expected, we get a clear error message in the test. Smart! In an older test, we were using
// @ts-ignore
, which sounds great too.From my perspective, the ref effect should always run before a layout effect which also runs before an effect. The ref should always be defined. If it's not, then there is a deeper issue, that a defensive logic will hide, make it harder to uncover.
So in userland, I would recommend the usage of
// @ts-ignore
or to throw, like in the test cases.