Do not allocate an array if no before input events

[nhunzaker]

Mostly following up on #7642 (comment).

BeforeInputEventPlugin returns [null, null] a lot - I think every time an event dispatches. I also think this leads to a bunch of null/empty checks later down the event pipeline that could be eliminated, though I didn't address them here (maybe they would get easier to identify as Flow types trickle down).

This also saves an array on every single event dispatch, which may or not be substantial, but the fix is straightforward, so I thought I'd give it a try.

[aweary]

I'm surprised that changing the return type doesn't break any tests, do you know if there are cases in our test suite that returns [null, null]?

[nhunzaker]

[null, null] returns for just about every single event plugin test that executes the EventPluginHub.extractEvents code path.

Quickly scanning (throwing on [null, null]), this is 22 of 24 SimpleEventPlugin tests, 7 of 9 ChangeEvent plugin tests, and a handful of other event system tests.

[nhunzaker]

Actually, if I'm interpreting the coverage correctly, BeforeInputEventPlugin has pretty weak coverage:

It's possible this is just really hard to test (keyboard stuff). Looks like neither event types (composition or beforeInput) ever instantiate.

[aweary]

Got it. This is eventually passed to accumulateInto which accepts either an item or array of items, so it works just fine.

[aweary]

Have you measured any non-trivial performance/memory usage improvements with this? I'm hesitant to accept this unless there's a definite win, since it hurts readability a bit.

[nhunzaker]

That's a good question. Technically it's a bit of extra memory rust, but I don't think it's worth it for a minor performance gain (Though I'd also be happy to decompress the ternary into an if/else for readability).

Mostly this just made things noisy when stepping through extractEvents and the change is trivial. Most people will probably never have to deal with that.

[nhunzaker]

@aweary I'll try to capture something more concrete today. Beyond that, do you think it's worth getting test coverage for more of this module?

[nhunzaker]

@aweary benchmarking this is kind of an interesting challenge for this, but it looks like what you'd expect: nothing substantial

This is partly intuition, but I wrote up a benchmark here https://github.com/nhunzaker/react-before-input-change-bench but it's not fantastic. Either way, nothing significant.

[nhunzaker]

Feel free to close this one out, though I am sort of curious if this will come up if Flow types move down into more of the event system.

Thanks for the time, either way.