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

fix: Check for forwardedRef in withGlobalEvents #7710

Merged
merged 1 commit into from
Jul 4, 2018
Merged

Conversation

tofumatt
Copy link
Member

@tofumatt tofumatt commented Jul 4, 2018

Fix #7707

Description

If a component isn't setting a ref then forwardedRef will be null and the block will crash. This checks for the ref first.

How has this been tested?

Ran it locally and things seem fine, and it fixes the problem in the issue.

@tofumatt tofumatt requested a review from a team July 4, 2018 15:42
// Any component using `withGlobalEvents` that is not setting a `ref`
// will cause `this.props.forwardedRef` to be `null`, so we need this
// check.
if ( this.props.forwardedRef ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sort of makes sense. @nerrad, how do you handle this in your PR?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well the pr is simply passing through forwardedRef to the components. I think HOC's will still need to handle the forwardedRef similarly (depending on how ref is used within the component the HOC is wrapping).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So to be clear, currently the createHigherOrderComponent is just passing along forwardedRef through the HOC to the WrappedComponent. This means, that it's still possible that forwardedRef is null. What I could maybe do is set forwardedRef to noop when ref is null?

@gziolo gziolo added the [Type] Bug An existing feature does not function as intended label Jul 4, 2018
@gziolo gziolo added this to the 3.2 milestone Jul 4, 2018
@gziolo gziolo added the [Priority] High Used to indicate top priority items that need quick attention label Jul 4, 2018
Copy link
Member

@jorgefilipecosta jorgefilipecosta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to fix the problem in my tests, and given the severity of the bug, we should probably merge it.

That said I'm not certain if this is the best fix or not as I still don't have total context about what caused the problem. Maybe we can merge this for now and if we have a better solution later we can improve.

@mcsf
Copy link
Contributor

mcsf commented Jul 4, 2018

Let's merge for the fix, then have a better plan for refs.

@mcsf mcsf merged commit 6bf9832 into master Jul 4, 2018
@mcsf mcsf deleted the fix/7707-image-embeds branch July 4, 2018 16:49
@tofumatt
Copy link
Member Author

tofumatt commented Jul 4, 2018

Thanks!

If folks would preferSetting it to no-op we could do that, but it seems the same as checking for truthiness and only running the ref callback then… assuming this is the only place we deal with forwarded refs.

The no-op solution is more consistent and I considered it, I guess it's better in principle.

@nerrad
Copy link
Contributor

nerrad commented Jul 4, 2018

The no-op solution is more consistent and I considered it, I guess it's better in principle.

If your comments are in response to what I wrote above, I think what you have here is fine for now. I was mostly just thinking that the solution in the forwardRef work being done in #7557 could just set forwardedRef to noop if ref is null (thus wrappedComponents wouldn't need a conditional check)

@tofumatt
Copy link
Member Author

tofumatt commented Jul 4, 2018

Yeah, I'm just thinking it's nicer to just set it as a no-op function by default instead of conditionally checking it.

I think #7557 should go that route, it's easier to follow in my mind. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Priority] High Used to indicate top priority items that need quick attention [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Images and embeds do not work
5 participants