Change:
layout: docs next: tutorial.html --- <ins> ## JSFiddle The easiest way to start hacking on React is using the following JSFiddle Hello Worlds * **[React JSFiddle](http://jsfiddle.net/vjeux/kb3gN/)** * [React JSFiddle without JSX](http://jsfiddle.net/vjeux/VkebS/) ## Starter Kit </ins> Download the starter kit to get started. <div class="buttons-unit downloads">

Discussion:
I am having an issue with text based inputs in React 0.14.3 and React DOM 0.14.3. When the event is fired for an input, the input will be deselected. Here is what this looks like in the UI: ! Here is an example of my components. There is a top-level component, which describes the fields on the form. This component also holds the state of the form and is the only component that extends . For each field in the form, there is a child component—which each has a and child. The form also has one component, which, when clicked, will fire an function with the state of the form. With the exception of , these components are all stateless functional components. The components are controlled. They get their value from the top level form component. The state is properly updated in this top level after the event is fired—as you would expect things to typically work with a controlled form. This state is then passed down via props to the input. I've been trying to figure out what could possibly be the cause of this weird deselection issue, but haven't made any progress... any ideas? Thanks.
This causes it: On every render the is a different random value. When the key is different, then React will not reuse the old component. So you lose focus because the input got replaced.
Ah, right, that would make sense. Bad mistake! Thanks.
as a key is definitely a bad idea
Haha, yes. I have long sense moved away from this solution.

We need to host a standalone React component (DraftJS editor) inside a HTML5 application which will run on other JS framework, or even plain JS or jQuery. The code of the application is beyond our control, we are just a vendor of a component which adds some content, part of which is this React-based editor. Anyway, the most important part is that we need to add the component with the following code to an existing DIV. EditorComponent is a regular React component with some onClick events attached to its content (primarily toolbar buttons for the editor). I learned that React event model and its bubbling executes independently after the event bubbles all the way up to the document, and that if ev.stopPropagation() is called on native event, React events won't execute at all. That is understandable for situations where document contains only the React app / component at its root and no other content, meaning you have control over all events on the page from React code. However, when React component is just a small fraction of the entire page, it may be severely influenced by the rest of the page. The problem is that any event handling code above the component which calls ev.stopPropagation() cuts of the events of that smaller fraction, even that the event originated from the React component scope. That influencing code could very well be just some jQuery plugin, so even author of the page may not be able to rewrite their code for some special event handling. Here is a fiddle to demonstrate that: I believe that the point where the event chain breaks, allowing React to execute its events, should be the root element of React component, rather than the whole document. This way, React root element could be considered an isolation edge of the React application / component. ! I tracked the React event registration down to function ReactDOMComponent.ensureListeningTo(...) where I found the following code: I tried to change to to register the React event chain to the root of the React container, and tried it for several basic events (onClick, onMouseDown/Up) and it seems working for us as expected. React events are not influenced by stopping propagation at the native events outside of React component root, so the two differently implemented parts of the application can coexist in peace. I am not sure why ownerDocument was chosen over node in the implementation and if changing it to _node could break something important.

Please advise if the proposed solution seems viable (in that case consider a change to that), or for what reasons you wouldn't recommend it.
thanks for the well thought out and detailed issue! This is something that's been requested a number of times in the past, see is an open PR that implements essentially the same solution that you've proposed, you can read the comments there for some context on why this hasn't been done yet.
Thank you! I couldn't find them, probably because I was searching by problem keywords, not solution keywords :-) I willl observe them. If I understand it correctly, if we use only some basic events e.g. onClick in our small React components, and support latest enough versions of browsers, the temporary fix should be pretty safe. Or is there some set of DOM events that React listens to that are attached automatically regardless of whether we register them or not?
I’ll close as a duplicate of
We're changing this in React 17 to attach to roots.
If you want to try it, we released 17 RC yesterday with this change: