react: Bug: manually created 'change' events via new Event() don't trigger React event handlers

This is also useful for using native web components which can fire a change event when their value changes.

import { MyCustomThing } from "some-web-components-library"; // Native components, not react!

// doSomething() will not be triggered
<MyCustomThing onChange={() => this.doSomething()} />

It is surprising that React is not listening to change events inside an onChange handler.

This unfortunate implementation detail of react enforces developers to use aRef and manual code/bind to keep web components updated with react’s life cycle.

I understand the desire for encapsulated components, the part I don’t understand is why you want to fire native browser events instead of exposing your own component’s events via props. <MyInput onChange={...} /> and then do props.onChange() from MyInput whenever you need. What is the problem with that approach?

@gaearon Are there any instructions on how to properly create synthetic event based on change event of input element?

I would also like to be able to do this. I am building an AngularJS-in-React bridge, and I’m mapping Angular’s concept of two-way binding to React change events. This allows React to see each bridged Angular component as something akin to a <textarea /> and the calling React component can then capture its state and treat it as a controlled component.

I recognize that the very idea of this is unpleasant, but it is helping my team refactor our legacy AngularJS components into React from the top down. I’m also using an onChange prop to make this happen, and I don’t strictly need event bubbling, but it would make the abstraction less leaky to have a way of emitting change events from React components.

Here’s an illustration of that scenario of logging (page, section, component, action)

Say you’re logging ("myPage", "articlesSection", "favoriteButton", "click")

Using event bubbling you can make a global setup where you handle sections like

<TrackingSection sectionName="articlesSection">…content…

and deep down in there, some <FavoriteButton> component could do

onClick(e) {
  e.trackingComponent = 'favoriteButton';
  e.trackingAction = 'click';
}

then TrackingSection could have it’s own handlers where it does

onClick(e) {
  if (e.trackingComponent && e.trackingAction) {
    e.trackingSection = this.props.sectionName;
  }
}

and then we log the event when it hits the top of the page if the event has all the expected parts.

If the section needs to discern between events, only log some and not others, or attach extra info for some, that can all happen right there and everything further down the tree can be agnostic about where they’re used - don’t have to thread extra props through or read from Context or import some section-specific tracking util.

It’s a really lightweight way of letting a button or input component say, “this happened, if you care” and letting a section say “I do care, thanks”. And if you need to modify the tracking at more places in the tree that’s easy too.

We do use onChange props as well, but we still find that event bubbling is useful for a couple reasons:

1. Most common usage is for instrumentation: you can listen to bubbled events from anywhere in the tree, which makes it easy to do things like track whether users interact with a certain section of the page (can fire an analytics event only for the first interaction in that section).

   An advanced use of this: modify events intended for logging as they travel up the tree to gather context so you can log (page, section, component, action) without needing any knowledge of section from the input where an event originates. i.e. the section component could catch the event and add a property e.logging.section = "mySectionName".

2. Centralizing handling: Our custom Form component is the thing that knows how to fire actions to the store and route them to the right form there. Input components emit, then the form catches the bubbled events and fires actions using props the form has. Again, saves us from having to pass that info down.

If we were starting from scratch we could use Context to accomplish a lot of this, but I’m not convinced it’s a better path.
-If you want to keep the ability to modify an event more locally before it reaches someplace higher up, or just generally want the ability to get callbacks further up the tree, you end up needing to implement something that looks a whole lot like bubbling, and in that case why not just use the bubbling that’s built in. -If you don’t need that, Context could solve it well - just use it to pass down some bound functions or all the raw info needed for an input component to directly fire analytics events or actions to stores.

In our case, switching implementations would be expensive and risky, so just trying to continue to make it cleaner and easier to use without a drastic change.