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

Add warning when reading from event which has been returned to the pool #5940

Merged
merged 1 commit into from Feb 18, 2016

Conversation

Projects
None yet
5 participants
@kentcdodds
Contributor

kentcdodds commented Jan 29, 2016

This is a WIP. I just want to make sure that I'm headed in the right direction for solving #5939

I'm not certain where the logic for deconstructing SyntheticEvents occurs. My guess is it's an abstraction that utilizes the EventInterface.

Also, what's the proper way to reference NODE_ENV for doing this only in development mode.

Thank you for helping a newbie to the codebase :-)

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 29, 2016

Member

Rather than throw, I think it should generate a warning.
Here is a another work-in-progress PR you can use as a reference: #5744

Member

gaearon commented Jan 29, 2016

Rather than throw, I think it should generate a warning.
Here is a another work-in-progress PR you can use as a reference: #5744

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 29, 2016

Member

I think these lines might be relevant:

for (var propName in Interface) {
this[propName] = null;
}

Member

gaearon commented Jan 29, 2016

I think these lines might be relevant:

for (var propName in Interface) {
this[propName] = null;
}

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Jan 29, 2016

Contributor

Rather than throw, I think it should generate a warning.

Ah, yes, that's right. Thanks for the reference 👍

Contributor

kentcdodds commented Jan 29, 2016

Rather than throw, I think it should generate a warning.

Ah, yes, that's right. Thanks for the reference 👍

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Jan 29, 2016

@kentcdodds updated the pull request.

facebook-github-bot commented Jan 29, 2016

@kentcdodds updated the pull request.

@zpao

This comment has been minimized.

Show comment
Hide comment
@zpao

zpao Jan 29, 2016

Member

https://github.com/facebook/react/blob/master/src/shared/utils/PooledClass.js#L102-L111 is another place to look. That's what get's run to add pooling to a class, generating a new class with a static release method which calls the destructor (as @gaearon linked to).

Member

zpao commented Jan 29, 2016

https://github.com/facebook/react/blob/master/src/shared/utils/PooledClass.js#L102-L111 is another place to look. That's what get's run to add pooling to a class, generating a new class with a static release method which calls the destructor (as @gaearon linked to).

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 29, 2016

Member

Another thing is you might want to put the warning code into a “devtool” which is a new work-in-progress API for doing dev-only things. See 251d6c3 and #5590 for inspiration.

Member

gaearon commented Jan 29, 2016

Another thing is you might want to put the warning code into a “devtool” which is a new work-in-progress API for doing dev-only things. See 251d6c3 and #5590 for inspiration.

@zpao

This comment has been minimized.

Show comment
Hide comment
@zpao

zpao Jan 29, 2016

Member

Might be tricky as a "devtool" since you need to add getters, which doesn't fit so well into the devtool event framework (at least as I understand it). Definitely work looking into though

Member

zpao commented Jan 29, 2016

Might be tricky as a "devtool" since you need to add getters, which doesn't fit so well into the devtool event framework (at least as I understand it). Definitely work looking into though

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Jan 29, 2016

Contributor

Updated. This is technically working, but there are some potential issues that I'll add some inline comments about.

Contributor

kentcdodds commented Jan 29, 2016

Updated. This is technically working, but there are some potential issues that I'll add some inline comments about.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Jan 29, 2016

Contributor

On possible suggestion is to set a property on the event called _nullified or _released and check for that before trying to access any properties.

Contributor

kentcdodds commented Jan 29, 2016

On possible suggestion is to set a property on the event called _nullified or _released and check for that before trying to access any properties.

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Jan 29, 2016

@kentcdodds updated the pull request.

facebook-github-bot commented Jan 29, 2016

@kentcdodds updated the pull request.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Jan 29, 2016

Contributor

Heh... Still got some work on this, I've got quite a few failing tests in the full test suite and some odd behavior in the stopPropogation test (looks like console.error is called 14 times with my warning for some reason).

Contributor

kentcdodds commented Jan 29, 2016

Heh... Still got some work on this, I've got quite a few failing tests in the full test suite and some odd behavior in the stopPropogation test (looks like console.error is called 14 times with my warning for some reason).

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Jan 29, 2016

Contributor

I think the problem is that when we restore an event, we need to re-defineProperty the object (only in __DEV__) otherwise it will run through my getter/setter and log the warning.

Let me know if that sounds wrong. I'll push what I've got so far for review and keep working on it

Contributor

kentcdodds commented Jan 29, 2016

I think the problem is that when we restore an event, we need to re-defineProperty the object (only in __DEV__) otherwise it will run through my getter/setter and log the warning.

Let me know if that sounds wrong. I'll push what I've got so far for review and keep working on it

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Jan 29, 2016

@kentcdodds updated the pull request.

facebook-github-bot commented Jan 29, 2016

@kentcdodds updated the pull request.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Jan 29, 2016

Contributor

Great. I'm ready for feedback now. All tests are passing. I have a linting question I'll add as an inline comment. I'm not solid on this approach, so definitely willing to make changes to how things work or the style of the code. 👍

Contributor

kentcdodds commented Jan 29, 2016

Great. I'm ready for feedback now. All tests are passing. I have a linting question I'll add as an inline comment. I'm not solid on this approach, so definitely willing to make changes to how things work or the style of the code. 👍

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Jan 29, 2016

@kentcdodds updated the pull request.

facebook-github-bot commented Jan 29, 2016

@kentcdodds updated the pull request.

@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Jan 29, 2016

Contributor

@zpao

Might be tricky as a "devtool" since you need to add getters, which doesn't fit so well into the devtool event framework (at least as I understand it). Definitely work looking into though

Potentially worth emitting an event whenever someone attempts to access a variable on an event object. In addition to solving this issue... That would open a bunch of doors, like having a devtool that warns if you persist an event but never subsequently read from that event, etc. It would be totally doable, if we wanted to.

Anyway, probably not worth churning this PR at this point, but @gaearon is correct that it would be good to start shifting this stuff over to the devtool, and I think the devtool could be a good fit in this case.

Contributor

jimfb commented Jan 29, 2016

@zpao

Might be tricky as a "devtool" since you need to add getters, which doesn't fit so well into the devtool event framework (at least as I understand it). Definitely work looking into though

Potentially worth emitting an event whenever someone attempts to access a variable on an event object. In addition to solving this issue... That would open a bunch of doors, like having a devtool that warns if you persist an event but never subsequently read from that event, etc. It would be totally doable, if we wanted to.

Anyway, probably not worth churning this PR at this point, but @gaearon is correct that it would be good to start shifting this stuff over to the devtool, and I think the devtool could be a good fit in this case.

@@ -92,15 +102,6 @@ assign(SyntheticEvent.prototype, {
preventDefault: function() {
this.defaultPrevented = true;
var event = this.nativeEvent;
if (__DEV__) {

This comment has been minimized.

@kentcdodds

kentcdodds Jan 29, 2016

Contributor

This warning now happens when the property is accessed

@kentcdodds

kentcdodds Jan 29, 2016

Contributor

This warning now happens when the property is accessed

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Jan 29, 2016

@kentcdodds updated the pull request.

facebook-github-bot commented Jan 29, 2016

@kentcdodds updated the pull request.

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Jan 29, 2016

@kentcdodds updated the pull request.

facebook-github-bot commented Jan 29, 2016

@kentcdodds updated the pull request.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 30, 2016

Member

At this point I’ve given all feedback I could give, and what I see so far looks good, apart from minor nits above. Let’s wait for the maintainers to give their further comments. Thank you for contributing!

cc @jimfb

Member

gaearon commented Jan 30, 2016

At this point I’ve given all feedback I could give, and what I see so far looks good, apart from minor nits above. Let’s wait for the maintainers to give their further comments. Thank you for contributing!

cc @jimfb

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Jan 30, 2016

@kentcdodds updated the pull request.

facebook-github-bot commented Jan 30, 2016

@kentcdodds updated the pull request.

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Jan 30, 2016

@kentcdodds updated the pull request.

facebook-github-bot commented Jan 30, 2016

@kentcdodds updated the pull request.

@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Feb 11, 2016

Contributor

@kentcdodds Overall, this looks great to me. A couple of nitpicks. Also, I think it would be good to add an "integration" test (ie. render a component, simulate a click event, save the event, read from the event at the end of the test, and assert the warning fires). Just to sanity check that things are working.

Otherwise, I think we're good to merge.

Contributor

jimfb commented Feb 11, 2016

@kentcdodds Overall, this looks great to me. A couple of nitpicks. Also, I think it would be good to add an "integration" test (ie. render a component, simulate a click event, save the event, read from the event at the end of the test, and assert the warning fires). Just to sanity check that things are working.

Otherwise, I think we're good to merge.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Feb 11, 2016

Contributor

Happy to write the integration test. I haven't looked into how to do that yet, but I'd appreciate it if you could point me in the right direction to do that :-) Thanks for the feedback!

Contributor

kentcdodds commented Feb 11, 2016

Happy to write the integration test. I haven't looked into how to do that yet, but I'd appreciate it if you could point me in the right direction to do that :-) Thanks for the feedback!

@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Feb 11, 2016

Contributor

@kentcdodds A reasonable example is in ReactServerRendering-test.js, we have a test called "should have the correct mounting behavior". Specifically, the most interesting line is: ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(instance.refs.span));

A test would probably look something like this:

var event = null;
var instance = ReactDOM.render(<div onClick={function(e){event = e;}} />);
ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(instance));`
// TODO: assert warnings.length===0
event.nativeEvent;
// TODO: assert warnings.length===1
// TODO: assert warnings[0].contanis("error message text");
Contributor

jimfb commented Feb 11, 2016

@kentcdodds A reasonable example is in ReactServerRendering-test.js, we have a test called "should have the correct mounting behavior". Specifically, the most interesting line is: ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(instance.refs.span));

A test would probably look something like this:

var event = null;
var instance = ReactDOM.render(<div onClick={function(e){event = e;}} />);
ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(instance));`
// TODO: assert warnings.length===0
event.nativeEvent;
// TODO: assert warnings.length===1
// TODO: assert warnings[0].contanis("error message text");
@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Feb 16, 2016

@kentcdodds updated the pull request.

facebook-github-bot commented Feb 16, 2016

@kentcdodds updated the pull request.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Feb 16, 2016

Contributor

Hi @jimfb. Sorry this took a bit. I've updated the tests and added an integration test as you suggested. I think it's solid. One thing that I did change in response to your comments is I combined two tests. When I asserted the console output in the one test, I realized that it was pretty much identical to another. So I just merged the two into one. Let me know if you'd like to see that change.

Thanks for this opportunity to contribute! :D

Contributor

kentcdodds commented Feb 16, 2016

Hi @jimfb. Sorry this took a bit. I've updated the tests and added an integration test as you suggested. I think it's solid. One thing that I did change in response to your comments is I combined two tests. When I asserted the console output in the one test, I realized that it was pretty much identical to another. So I just merged the two into one. Let me know if you'd like to see that change.

Thanks for this opportunity to contribute! :D

@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Feb 18, 2016

Contributor

@kentcdodds This all looks good to me, thanks! But it looks like we broke lint (you can run locally with npm run lint or view the output here: https://travis-ci.org/facebook/react/jobs/109724188). Just fix the lint errors and do a "git commit --amend", and we should be good to go.

Contributor

jimfb commented Feb 18, 2016

@kentcdodds This all looks good to me, thanks! But it looks like we broke lint (you can run locally with npm run lint or view the output here: https://travis-ci.org/facebook/react/jobs/109724188). Just fix the lint errors and do a "git commit --amend", and we should be good to go.

@jimfb jimfb added this to the 0.15 milestone Feb 18, 2016

@jimfb jimfb self-assigned this Feb 18, 2016

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Feb 18, 2016

Contributor

(-‸ლ) thanks! The PR has been updated to fix linting.

Looking forward to my next opportunity to contribute ⭐️

Contributor

kentcdodds commented Feb 18, 2016

(-‸ლ) thanks! The PR has been updated to fix linting.

Looking forward to my next opportunity to contribute ⭐️

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Feb 18, 2016

@kentcdodds updated the pull request.

facebook-github-bot commented Feb 18, 2016

@kentcdodds updated the pull request.

jimfb added a commit that referenced this pull request Feb 18, 2016

Merge pull request #5940 from kentcdodds/pr/warn-event-pool-access
Add warning when reading from event which has been returned to the pool

@jimfb jimfb merged commit e8e56e8 into facebook:master Feb 18, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Feb 18, 2016

Contributor

Thanks @kentcdodds!

Contributor

jimfb commented Feb 18, 2016

Thanks @kentcdodds!

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Feb 18, 2016

Contributor

🎉 🎊

Contributor

kentcdodds commented Feb 18, 2016

🎉 🎊

@kentcdodds kentcdodds deleted the kentcdodds:pr/warn-event-pool-access branch Feb 18, 2016

@renovate renovate bot referenced this pull request Feb 2, 2018

Open

Update dependency react to v16 #29

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment