Proposal for Combo object for event handling

Do you want to request a feature or report a bug?

Proposal for feature

What’s the current behavior?

There are composite groups of events that fire in Android. By looking at one event, we cannot tell what the intended action of the user is. For example, an Enter after a Backspace in the middle of a word fires multiple input, keydown, beforeinput, compositionStart and select events which include events identified as delete and enter.

We cannot act on each event individually as it breaks Android usually resulting in Android’s DOM going out of sync with React’s virtual DOM. This ends in a crash.

To continue with this example, we know the fingerprint of an Enter is a set of events all fired one after the other which includes the Enter event. The Delete event somewhere in there is just a side-effect of how Android is manipulating the DOM as part of its way to handle Enter.

What’s the expected behavior?

What we want is a special object (the Combo) that we instantiate. It has a bunch of signatures in it. As the events fire, we want the combo to determine the right signature. Was this a delete? Was this an enter? At the end of period of time, we then want the correct event to fire or no event to fire if the signature indicates not to do anything at this time. This could happen, for example, if a user hits a key in the middle of a composition. We don’t want that to fire unless a compositionEnd is at the right position in the combo.

We also want to have a way to refresh the timeout in the Combo. Some combos have enough events in that that the requestAnimationFrame has a chance to fire before the combination of events has actually finished. To combat this, we restart the timer whenever we send an event to the Combo.

The Combo also needs to include snapshots of previous DOM and selection states. This is because some Combos need to revert the DOM back to a safe state so that it doesn’t cause React to crash. When Android manipulates the DOM without letting React know, we usually end up with a fatal error. The moment in time that the snapshot needs to revert to may be different depending on the final event. For this reason, the Combo should be able to take a snapshot when events are being sent to the Combo. The Combo can then select which Snapshot to revert to.

Related to https://github.com/ianstormtaylor/slate/issues/2062

[thesunny]

Matching and Rejecting

When a combo is finished, we need to match against several signatures. These signatures need these features:

• The ability to match a number of events in a specific order. For example, an onBeforeInput:enter followed by an input:delete.
• The ability to reject if we encounter an event that fails the signature. For example, perhaps the above is invalid if called after a compositionEnd.

The syntax for matching could be like this:

[
  {type: 'onBeforeInput:enter'},
  {type: 'onBeforeInput:delete'}
]

Two possible syntaxes for rejection.

The first is to make it part of the definition:

[
  {type: 'onBeforeInput:enter', notType: 'onCompositionEnd'},
  {type: 'onBeforeInput:delete'}
]

The second is to include it linearly:

[
  {notType: 'onCompositionEnd'},
  {type: 'onBeforeInput:enter'},
  {type: 'onBeforeInput:delete'}
]

They both indicated that a compositionEnd event cannot precede the onBeforeInput:enter event.

The benefit of the former is that we only need to look at one matcher at a time. The benefit of the second is a more readable format.

One way the former method could be implemented is that these matchers can simply be functions. The functions can return true (match), false (reject) or null skip this event for now.

[thesunny]

The ActionManager above is created the way it is in order to handle three use cases with respect to mapping a user action to a handler:

1. The action can be identified by a single event and can be handled immediately: In this use case, we use the onTrigger function and if there is a match, we event.preventDefault(), run the code that we need to run to handle the action, and then return true so that further onTrigger and onFinish functions aren’t called.

2. The action can be identified by a single event and must be handled at the end of the action: In this use case, we can also use onTrigger but we don’t preventDefault. Instead, we return a function instead of true and that function will be called at the end of the action (note: not in the spec above as I missed that use case earlier).

3. The action is identified through a composite of events and or DOM analysis (e.g. we know that enter was pressed because the DOM is split): In this case, we use onFinish and we have access to the manipulated DOM and an array of all events.