bd79be9b68
[react-core] Add experimental React Scope component API ( #16587 )
2019-08-29 12:06:51 +01:00
dce430ad92
[Flare] Rework the responder dispatching/batching mechanism ( #16334 )
2019-08-19 19:22:46 +01:00
42794557ca
[Flare] Tweaks to Flare system design and API ( #16264 )
2019-08-01 19:08:54 +01:00
ed72f40257
[Flare] Remove references to EventComponent ( #16206 )
2019-07-25 16:41:26 +01:00
5098891193
[Flare] Redesign core event system ( #16163 )
2019-07-23 23:46:44 +01:00
2c4d61e102
Adds experimental fundamental interface ( #16049 )
2019-07-19 22:20:28 +01:00
23b8a25345
[Flare] Remove responder flags to simplify logic ( #16084 )
2019-07-09 15:05:45 +01:00
67e3f3fb6e
[Flare] Revise responder event types ( #16081 )
2019-07-08 14:35:59 +01:00
c40075a72c
[Flare] Remove capture phase Flare events ( #16054 )
2019-07-04 21:30:46 +01:00
786186c692
[Flare] createInitialState -> getInitialState ( #16051 )
2019-07-04 18:06:18 +01:00
c64f40d718
[Flare] Remove dead event target code ( #16063 )
2019-07-04 13:10:55 +01:00
dc298fdf91
[Flare] Refinements to useEvent hook ( #15955 )
2019-06-21 23:10:55 +01:00
34ce57ae75
[Flare] Refine flow type annotations ( #15950 )
2019-06-21 12:32:43 +01:00
720db4cbe6
[Flare] Add useEvent hook implementation ( #15927 )
...
* [Flare] Add useEvent hook implementation
Validate hooks have decendent event components
Few fixes and displayName changes
Fix more responder bugs
Update error codes
* Add another test
* Address feedback
2019-06-20 19:12:40 -07:00
4a7a39b594
[Flare] Add RN build step for ReactTypes ( #15926 )
2019-06-19 13:27:10 +01:00
689beef6f5
[Flare] Move unstable_createEventComponent to ReactDOM ( #15890 )
2019-06-18 23:41:00 +01:00
353e0ee474
[Flare] remove stopLocalPropagation option + modify responder ownership ( #15889 )
2019-06-14 23:11:54 +01:00
a146c1f9ed
[Flare] Refactor of Press to fix various issues ( #15878 )
2019-06-14 22:52:26 +01:00
425473f43f
[Flare] Improve runtime performance of hit target intersection ( #15836 )
2019-06-07 15:57:10 +01:00
8cfcfe0fcb
[Flare] Fix ES6 issues with IE11 ( #15834 )
2019-06-06 18:38:46 +01:00
7b28ad119e
[Flare] EventPriority enum ( #15823 )
...
* Same as previous commit, but for Flare
I don't know what the public API for setting the event priority should
be. Right now it accepts a numeric enum, but is this what we want?
Maybe it should be a string enum? I've punted on this for now.
* Add test for hover events
2019-06-04 17:20:06 -07:00
287ef30bba
[Flare] Deeply prevent default on anchor elements ( #15750 )
2019-05-28 12:46:07 +01:00
b962adfc2b
[Flare] event component displayName is now mandatory ( #15717 )
2019-05-23 01:29:07 +01:00
121acae090
Flare: simplify dispatchEvent discrete argument ( #15694 )
2019-05-21 16:06:17 +01:00
1160b37691
Event API: Add responder allowMultipleHostChildren flag ( #15646 )
2019-05-16 19:03:38 +01:00
fec74f99da
Event API: ensure preventDefault works for nested targets ( #15633 )
2019-05-13 13:45:48 +01:00
e33e32db04
Event API: normalize event timeStamp property to be in event system ( #15598 )
2019-05-09 16:05:25 +01:00
51e66cf9fa
Experimental Event API: reduce code size of event modules ( #15590 )
2019-05-08 19:09:32 +01:00
ec6691a687
Event API: remove isTargetDirectlyWithinEventComponent ( #15546 )
2019-04-30 17:38:48 +01:00
bd88982fbf
Event API: use capture for all event listeners using experimental responder system ( #15526 )
2019-04-30 11:40:45 +01:00
d1f667acc0
Event API: follow up fixes for FocusScope + context changes ( #15496 )
2019-04-25 20:10:33 +01:00
de26d6dd36
typo fix ( #15493 )
...
changed ReactResponderContext.dispatchEvent otpions keys to options.
2019-04-25 09:37:35 +01:00
64e3da286f
Event API: Add FocusScope surface ( #15487 )
2019-04-25 02:01:09 +01:00
fa2fa3564d
Experimental event API: adds context.isTargetDirectlyWithinEventComponent ( #15481 )
2019-04-24 11:02:47 +01:00
d3af2f2a5d
Experimental Event API: add event component mount phase callback ( #15480 )
2019-04-24 10:41:24 +01:00
017d6f14b7
Experimental Event API: add rootEventTypes support to event responders ( #15475 )
...
* Adds rootEventTypes
2019-04-23 19:55:50 +01:00
784ebd8fa9
Experimental event API: rework the propagation system for event components ( #15462 )
2019-04-23 11:50:48 +01:00
9ebe1768a8
Experimental Event API: Redesign event responder propagation ( #15408 )
...
* Event API: Redesign event instance propagation
2019-04-13 20:37:39 +01:00
543353a043
Experimental Event API: Remove "listener" from event objects ( #15391 )
2019-04-12 11:53:40 +01:00
9672cf621b
Experimental Event API: adds stopPropagation by default to Press ( #15384 )
2019-04-11 20:00:20 +01:00
dd9cef9fc0
Experimental Event API: Add targets and responder utility method for finding targets ( #15372 )
2019-04-10 18:52:34 +01:00
c64b330032
Move EventTypes to ReactTypes ( #15364 )
2019-04-10 09:55:56 +01:00
aece8119cf
Refactor EventComponent logic + add onOwnershipChange callback ( #15354 )
2019-04-09 12:47:32 +01:00
b93a8a9bb8
Experimental event API: refactor responder modules for lifecycle inclusion ( #15322 )
2019-04-04 23:28:23 +01:00
89064fe68d
Adds displayName to EventComponent and EventTarget ( #15268 )
...
* Adds displayName to EventComponent and EventTarget
2019-04-03 12:24:25 +01:00
b83e01cade
Adds more scaffolding for experimental event API ( #15112 )
...
* Adds more scaffolding for experimental event API
2019-03-20 11:20:17 +00:00
55cc921c5d
Adds react-events package for internal testing ( #15150 )
...
* Adds react-events package for internal testing
2019-03-19 15:12:45 +00:00
0c03a47436
Adds experimental event API scaffolding ( #15108 )
...
* Adds experimental event API scaffolding
2019-03-14 17:02:42 +00:00
961eb65b4b
Use unique thread ID for each partial render to access Context ( #14182 )
...
* BUG: ReactPartialRenderer / New Context polutes mutable global state
The new context API stores the provided values on the shared context instance. When used in a synchronous context, this is not an issue. However when used in an concurrent context this can cause a "push provider" from one react render to have an effect on an unrelated concurrent react render.
I've encountered this bug in production when using renderToNodeStream, which asks ReactPartialRenderer for bytes up to a high water mark before yielding. If two Node Streams are created and read from in parallel, the state of one can polute the other.
I wrote a failing test to illustrate the conditions under which this happens.
I'm also concerned that the experimental concurrent/async React rendering on the client could suffer from the same issue.
* Use unique thread ID for each partial render to access Context
This first adds an allocator that keeps track of a unique ThreadID index
for each currently executing partial renderer. IDs are not just growing
but are reused as streams are destroyed.
This ensures that IDs are kept nice and compact.
This lets us use an "array" for each Context object to store the current
values. The look up for these are fast because they're just looking up
an offset in a tightly packed "array".
I don't use an actual Array object to store the values. Instead, I rely
on that VMs (notably V8) treat storage of numeric index property access
as a separate "elements" allocation.
This lets us avoid an extra indirection.
However, we must ensure that these arrays are not holey to preserve this
feature.
To do that I store the _threadCount on each context (effectively it takes
the place of the .length property on an array).
This lets us first validate that the context has enough slots before we
access the slot. If not, we fill in the slots with the default value.
2018-11-09 15:38:20 -08:00
7685b55d27
Remove unstable_read() in favor of direct dispatcher call ( #13861 )
...
* Remove unstable_read() in favor of direct dispatcher call
* This no longer throws immediately
2018-10-16 14:58:00 -04:00
Dominic Gannaway
Andrew Clark
shubham
Sebastian Markbåge
Dan Abramov