Document interaction between native and React events #220
Conversation
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed. If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
|
Deploy preview ready! Built with commit 32a9908 |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
| @@ -58,6 +58,10 @@ Here, `e` is a synthetic event. React defines these synthetic events according t | |||
|
|
|||
| When using React you should generally not need to call `addEventListener` to add listeners to a DOM element after it is created. Instead, just provide a listener when the element is initially rendered. | |||
|
|
|||
| > Note: | |||
| > | |||
| > For performance reasons, React events are not guaranteed to be installed on the element they are created on. This means that using `stopPropagation` from event handlers installed outside of React might not be able to stop React events from occurring and vice versa. | |||
There was a problem hiding this comment.
I'm not sure about the wording "installed on" or "installed outside of".
There was a problem hiding this comment.
I was looking for a good word here. I am not happy with "installed" myself, but it was the best I could come up with. Suggestions welcome!
There was a problem hiding this comment.
(Sorry. Hit enter before I intended to.) What do you think about something like this?
Note:
React uses event delegation for performance reasons. Generally this is not observable but it is worth noting if you also use the browser's event system directly (via
addEventListener). For example, callingstopPropagation()on a synthetic event will not prevent a native event handler from being executed.
There was a problem hiding this comment.
(I'm also not sure about the wording here. Just offering an idea.)
There was a problem hiding this comment.
@bvaughn Sorry for the late reply. I like your version better than mine, although I needed a bit to understand what "observable" meant in this context. I was looking for a technical meaning. But that is bikeshedding territory.
There was a problem hiding this comment.
No problem. Want to take a stab at updating the wording then?
Sync with reactjs.org @ b91049c
|
I am sorry for dropping this. With React 17, this seems obsolete, closing. |
…ontent/docs/static-type-checking.md (reactjs#220) 原文：https://reactjs.org/docs/static-type-checking.html
Closes #68.
I tried to make the wording as concise and clear as possible, although there is certainly room for improvement. The wording in both files is slightly different to fit the style of the respective document better.