Seperate beforeBlur/afterBlur

[trueadm]

This PR does two things:

• Moves the logic for handling beforeblur/afterblur to a seperate flag internally. Previously, they used the enableCreateEventHandleAPI flag, but really the feature of adding functionality for handling focus before and after an active element is removed/hidden has nothing to do with createEventHandle.
• Adds support for the React event prop so it's possible to do <div onBeforeBlur={...}>. onAfterBlur isn't done via a React prop, as the event is always dispatched on the document, so no DOM element will ever pick it up.

These changes make it possible to extract the important logic around handling focus management, without needing to use createEventHandle or needing to change how the timing occurs in React. One of the internal features we have, which is why this previously wasn't already carried out, is that fact we attach events to the experimental Scopes API. In terms of handling that, we could support adding React prop events to either Scopes or Fragments (<Fragment onClick={...}>), but really that is a discussion for another day.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 9868b77:

Sandbox	Source
React	Configuration

[sizebot]

No significant bundle size changes to report.

Size changes (experimental)

Generated by 🚫 dangerJS against 9868b77

[sizebot]

No significant bundle size changes to report.

Size changes (stable)

Generated by 🚫 dangerJS against 9868b77

[necolas]

Adds support for the React event prop so it's possible to do

Do we need to expose this event on the props? That seems to make the change more invasive. These custom events could instead be seen as a way for ReactDOM to communicate information it has to user-space code that can't otherwise know about it.

[trueadm]

@necolas Nicolas Gallagher The reason here is to provide an alternative to needing a ref where timing is an issue. E.g. where we can’t avoid sync focus(). If you have an on* event, React can ensure the listener is added during render, avoiding the timing problem.

[necolas]

Can't we work around that react problem by delegating to the document? Adding the prop makes it an official part of the public API

[trueadm]

@necolas The event bubbles, so you can already listen to the event on the document. The issue is timing still. We found internally, that we need to listen to add the listeners for this event before the layout phase occurs, as mutations can occur in the layout phase, which trigger the event. That's why we worked around the timing issue by making Scopes attach their refs before the layout phase. We don't have to add this event prop, but then how else can you listen to it?