Event Handlers on Fragments

[sebmarkbage]

The use case is when an abstraction wants to listen to some event bubbling up and intercept the event somehow.

function Abstraction(props) {
  return <div onClick={() => props.onAction()}>{props.children}</div>;
}

Perhaps there is some state and context involved too.

This works fine today as long as you can wrap it in a <div />. However, you can't necessarily always do that. I hear that some of this will be relaxed but conceptually I think the constraints will remain in many environment that you don't want a wrapper element around these.

<ul>
  <Abstraction onAction={...}>
    <li>A</li>
    <li>B</li>
  </Abstraction>
</ul>

<table>
  <tbody>
    <Abstraction onAction={...}>
      <tr><td>A</td></tr>
      <tr><td>B</td></tr>
    </Abstraction>
    <Abstraction onAction={...}>
      <tr><td>A</td></tr>
      <tr><td>B</td></tr>
    </Abstraction>
  </tbody>
</table>

It would be nice to be able to use fragments for this.

function Abstraction(props) {
  return <Fragment onClick={() => props.onAction()}>{props.children}</Fragment>;
}

It is easy to implement with the synthetic event system but I suspect it is doable with other approaches too (including just inserting an element called <fragment /> in the DOM).

To implement this we'd need somewhere to store the "current" props. We can use the stateNode on fragment fibers to hold that. We also need to schedule commit phase effects whenever the set of event handlers on a fragment changes. In the commit phase we update the stateNode on both Fibers to hold the "current props".

That way when we bubble up the fiber return pointers, we know that stateNode holds the current set of props and those will be the ones we extract event handlers from.

[sophiebits]

We'd need something like display: contents in order to actually insert a DOM node. It's not clear that this is really feasible without the synthetic event system AFAICT.

[sebmarkbage]

I believe there are plans to allow for more of these forms in browsers, and even if the normal DOM node solution doesn't work, a plausible future addition would be to have first class fragment nodes. @trueadm has been really passionate about this. So I think there's at least a plausible future where this capability just works natively.

However, even without that, it doesn't have to use the full synthetic event system, it can also intercept, and redirect locally. We probably want that anyway for batching/controlled/default priorities. For any local event handler attached on a DOM node, it can also call any parent fragments. Enter/leave would have an extra enter/leave but that's not such a big deal since we've noticed that you typically want a timeout for such uses anyway.

[clemmy]

Perhaps I'm missing something, but doesn't inserting an element called <fragment /> into the DOM mean that we're still adding a wrapper element?

[gaearon]

Yes. The post doesn't say it's necessary, just that it's technically possible without a synthetic event system.

[trueadm]

I'm not too sure about this idea when it comes to the web. I personally feel fragments should not have any events and users should stick to using elements for when they need events.

I always envisaged (and originally proposed a spec for a native DOM fragment) they were special nodes that had no layout/styling properties – meaning they couldn't have events attached to them. For example, how can mouse events even interact with something that has no positional rectangle? They were meant to act very much like how DocumentFragments and TextNodes do now instead of how Elements do.

[aweary]

For example, how can mouse events even interact with something that has no positional rectangle?

I would assume that event listeners on fragments should only listen to events dispatched by children, either in the capture or bubble phase, so there would be no concept of an event being dispatched on a fragment directly.

[trueadm]

@aweary What if I had nested fragments within fragments or portals within fragments? How would onResize work or onBlur work with fragments too? I'm generally curious as to how these can be solved in the synthetic event space as it could help create a native fragment polyfil for my implementation idea I had.

[aweary]

@trueadm I haven't given this idea a lot of thought, but conceptually fragment events could just be synthetic "aggregates" which let you signal to the synthetic event system that you want to listen to some set of events on the children of the fragments. So if you had a fragment listening for blur events it would register a listener for the appropriate elements rendered in that subtree (maybe by using some ancestor tracking to know which fragment(s) its contained within).

For nested fragments the event would move up/down the tree, and any matching fragments would be triggered, just like how it works now with DOM elements. I think the primary use case is wrapping some direct children, like a tr in tbody, so nested fragments could potentially be restricted somehow if it causes problems, I'm not sure.

I'm not sure about portals.

[pyromaniac]

I really miss this feature while trying to create proper abstractions. In order to listen to events from the inside, I have to wrap everything with additional nodes. To avoid the creation of the nodes I have to invent function children interface, pass event listeners there as arguments and manually assign them to the topmost nodes inside. This is not easily testable or clean interface. I can only imagine how much easier my life will become after events support for Fragment.

I can double the implementation proposal: it should call the handler as soon any descendant node emitted the event. As far as I got, it is already implemented this way internally, the Synthetic Events have their own bubbling phase which happens later than the engine one and it bubbles up through all the React components.

[pyromaniac]

Hm, unfortunately, this feature is not mentioned in #12152 :( The guys are being focused on async rendering and stuff.

[TrySound]

@pyitphyoaung This is only discussion without decision. Do not expect this behavior will be implemented, maybe won't.

[pyromaniac]

Yeah, I realize this but since the feature is mentioned in the official docs (https://reactjs.org/docs/fragments.html#keyed-fragments) I've thought they at least have plans. Btw, you've missed my handle.