Summary:
Changelog: [Internal]
Order of events dispatched to JS matter. If we remove duplicate events, we shouldn't change order of types.
So If we have order of events
A -> B -> C
and inserting a new event A for the same target, we shouldn't delete the first A, as there might be logic that depends on event B being preceded by A.
What we can do though, is delete previous event of the same type and target in queue if we would be adding subsequent event.
So when we have events
A -> B -> C
and we are about to add event C to the queue which goes to the same target, we can delete the first C before inserting the new one.
Reviewed By: shergin
Differential Revision: D22135931
fbshipit-source-id: 1dadd1688516330be07c4251f446f77ca08eaa87
Summary:
Changelog: [Internal]
`BatchedEventQueue::enqueueUniqueEvent` goes over event queue and deletes previous event of the same type and same target.
This is useful for ScrollView for example where only the latest event is relevant.
This only affects ScrollView scroll event, other events take the original code path.
Reviewed By: mdvacca
Differential Revision: D21648906
fbshipit-source-id: a80ad652058fd50ebb55e24a87229cdc1764b591
Summary:
A couple of small changes:
1. `onEnqueue` was decoupled from `enqueueEvent` for easier and unified overiding in subclasses (other methods will call `onEnqueue` soon);
2. `flushEvents` was decoupled from `onBeat` (we will put more stuff into `onBeat` soon).
Reviewed By: mdvacca
Differential Revision: D14205769
fbshipit-source-id: 574c2b2caaa6432bc7782b2f3bc147fa1fb82bd3
Summary: That's bummer that we have to do it, but it's actually reasonable. Files in `core` and `events` depend on each other creating circular dependencies and other similar hard problem.
Reviewed By: mdvacca
Differential Revision: D14195022
fbshipit-source-id: 96a44ae28631cc9ccd7d7de72a94526f9e0dd12a
Samuel Susla
Andres Suarez
Valentin Shergin