We can avoid recreating the merged context object if the context provider work was reused. This is essential to avoid allocations for deep setState() calls.
As per discussion, this is better because then this code only runs for the class type of work. We will still need to fix bailouts for deep setState calls.
It is error-prone to push and pop context in begin or complete phases because of all the bailouts. Scheduler has enough knowledge to see if pushing is necessary because it knows when we go inside or outside the tree.
I'll plan to change all of our console.error and component-tree expects to expectDev. It's a little annoying that we need to make sure tests don't throw (see my change to normalizeCodeLocInfo) but any alternative would seem to require two separate test runs or a much more cumbersome syntax.
* Handles risky callbacks on setState. Fixes#8238
* Updates try-catch to cover `callback` when context is not present.
* Updates code to trapErrors instead of swallowing them.
* Fixes flow errors
* Incorporates review comments
* Traps only the first error.
Removes `callbackWasCalled` and updates fiber tests.
I came up with a contrived case of where nested controlled events could
fire within the same batch - but on different targets.
I think we came to the conclusion that controlled values typically cannot
use preventDefault so it is ok that they don't flush until after the event
has finished. So therefore we accumulate a queue of all the nested targets
within a batch and then restore state on all of them.
I'm still skeptical that this is the correct way to do controlled values.
The reason we have to do them in a single event loop is because when you
type, the sequence of values that get accepted or not can matter. I wonder
if there is a scenario we can come up with where you can fire multiple
inner events in an event loop and end up with batching causing problems.
This effectively just reimplements asap again but with no allocations for
a single target and no closure allocations.
* Make the Shallow Rendering example clearer
I was reading through the documentation, and I found that the `render` call on the `renderer` was missing.
* Use a regular function to define MyComponent
* Use _hostContainerInfo to track test renderer options
The transaction is not available when unmounting or updating the
instance, so we track it using _hostContainerInfo
* Throw if hostContainerInfo is not populated in getPublicInstance
* Linting fixes
* Remove transaction from ref lifecycle code path
We don't need to pass the transaction around anymore since we store the
test options on _hostContainerInfo instead
* Remove unused argument
If a controlled target fires within another controlled event, we should not
restore it until we've fully completed the event. Otherwise, if someone
reads from it afterwards, they'll get the restored value.
Not super happy with this particular solution.
* took codes.json from the 15-dev branch
* fixed react:extract-errors task in gulpfile
* generated error codes
* Revert "generated error codes"
This reverts commit b8f3aeed9d8f0d469edd5f6623fa6090930594d8.
* Added a README for the error code system
This reverts commit a878c3056d.
The previous stuff that this builds on didn't successfully land fully. Since I
want to measure this in isolation, I'll revert this for now.
This just reads events from the props instead of storing them in a
listener back.
I had to rewrite a bunch of tests to cover this model.
I removed the tests that just test the adding and removing over listeners
since there is no equivalent behavior anymore.
This reverts the implementation in 33325ad009.
I didn't mean to merge the implementation since it is incorrect and incomplete.
I meant to just merge the unit test.
* Ensure that we're listening to all onChange dependencies for controlled inputs
When there is no onChange event handler, we should still listen to it to
ensure controlled values get reset.
There is warning associated with this but the prod behavior should still be
respected.
* Rerun tests
When there is no onChange event handler, we should still listen to it to
ensure controlled values get reset.
There is warning associated with this but the prod behavior should still be
respected.
Dan Abramov
Ben AlpertandDan Abramov
Ben AlpertandGitHub
Ankeet MainiandAndrew Clark
Samuel ScheiderichandKevin Lacker
Michele BertoliandDan Abramov
Brandon DailandDan Abramov
Eoin HennessyandDan Abramov
Shuhei KagawaandDan Abramov
Satoshi NakajimaandDan Abramov
Arni FannarandKevin Lacker
Guilherme OenningandDan Abramov
jddxfandDan Abramov
Ville ImmonenandDan Abramov
Toru KobayashiandDan Abramov
Andrew Clark
Kevin LackerandDan Abramov
Samer BunaandDan Abramov
NateandDan Abramov
Keyan ZhangandDan Abramov
iurii kucherovandDan Abramov
Robert HaritonovandBrandon Dail