Skip to content
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

[Popover] Fix wrong getContentAnchorEl definition #12562

Merged
merged 2 commits into from
Aug 18, 2018

Conversation

duvet86
Copy link
Contributor

@duvet86 duvet86 commented Aug 17, 2018

Update typescript definition.

Closes #12539

@oliviertassinari oliviertassinari changed the title Fixe for Misleading Popover getContentAnchorEl warning when using typescript. [Popover] Fix wrong getContentAnchorEl definition Aug 17, 2018
@eps1lon
Copy link
Member

eps1lon commented Aug 17, 2018

While this is indeed correct I would rather change the warning message. This change could theoretically be applied to most optional props which would add way to much noise in my opinion.

You could also pass 0 or false and suppress the warning. The only difference is that the component would not behave as expected and prop-types would issue a warning. Because prop-types considers optional props to match T | null | undefined. However both flow and typescript consider optional types to be T | undefined.

@eps1lon
Copy link
Member

eps1lon commented Aug 18, 2018

From my experience people are not that interested in semantic versioning considering typings. While this would be a breaking change at compile time the runtime would be unaffected.

Since you just bumped your typescript version to the next major (#12409) I think it's ok to define a consistent typing considering optional types and include that change in the next minor.

@oliviertassinari
Copy link
Member

oliviertassinari commented Aug 18, 2018

@eps1lon I have to admit, I don't follow here you are going with this. What do you think we merge this pull request so we stay consistent with the other occurrences of null in the TypeScript definition? And then, we work on a global better answer? cc @pelotom

@eps1lon
Copy link
Member

eps1lon commented Aug 18, 2018

That is completely fine by me.

I just have to be a little pedantic here: The warning should also mention null or undefined if we merge this.

@oliviertassinari oliviertassinari merged commit 4f3ef62 into mui:master Aug 18, 2018
@oliviertassinari
Copy link
Member

@duvet86 It's a great first pull request on Material-UI 👌🏻. Thank you for giving it a shot!

@pelotom
Copy link
Member

pelotom commented Aug 18, 2018

I agree with @eps1lon, I would rather change all the TS definitions to exclude null. It’s common practice in TS to only use undefined for “nully” things, because of its compatibility with optional (?) properties. There’s even a tslint rule to forbid the use of null.

@oliviertassinari
Copy link
Member

At least, the warning message was updated :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants