* Initial React DevTools support for Fiber
* Record a newly failing irrelevant test
This is fine because we don't use it in Stack anyway (at least not that part), and we also rely on Set/Map in other parts of code.
The newly failing test is the one saying "it works without Map/Set".
* Explicitly check for Fiber DevTools support
This lets us ignore pre-Fiber DevTools instead of crashing them by injecting a different API.
* Track the roots in DevTools instead
* Lol Dan this is not how warnings work in our codebase
* Move injection to the renderer
* Notify DevTools about unmounts
* Make it work in production
* Fix lint and flow
* Fixups
* Address feedback
When visiting the yields, the root is the stateNode of the coroutine. If
its return value is wrong we'll end up at the alternate of the
workInProgress which will start scanning its children which is wrong.
There are a few different issues:
* Updates result in unnecessary duplicate placements because it can't find the current fiber for continuations.
* When run together, coroutine update and unmounting tests appear to lock down in an infinite loop. They don't freeze in isolation.
I don't have a solution for this but just leaving it for future fixes.
Coroutines was kind of broken because it tried to do reparenting and
enabling state preservation to be passed along the coroutine. However,
since we couldn't determine which Fiber was "current" on a reified yield
this was kind of broken.
This removes the "continuation" part of yields so they're basically just
return values. It is still possible to do continuations by just passing
simple functions or classes as part of the return value but they're not
stateful.
This means that we won't have reparenting, but I actually don't think we
need it. There's another way to structure this by doing all the state in
the first phase and then yielding a stateless representation of the result.
This stateless representation of the tree can then be rendered in different
(or even multiple) locations.
Because we no longer have a stateful continuation, you may have noticed
that this really no longer represent the "coroutine" concept. I will
rename it in a follow up commit.
It is slightly more useful this way because when we want to find host nodes
we typically want to do so in the second phase. That's the real tree where
as the first phase is more of a virtual part of the tree.
* Add benchmarking tutorial
I've written what I hope is the simplest introduction to benchmarking React components. It's meant to be straightforward and easy to follow for beginners. If you agree that it would be helpful, I'd like to add it to the docs.
Would also welcome any and all feedback.
* Just put links together
* Reminder: strip quotes from attributes with JS code
Web developers who are used to standards-compliant HTML and XML will, out of habit, put quotes around all attributes because the standards require them. Other templating systems like ASP.NET also require (or at least allow) quotes around attributes that contain code. This behavior will get users into trouble in JSX because a quoted attribute is always treated as a string literal, even if it contains curly-braced javascript code. Let's add to the docs to help newbies evade this problem.
* Tweak wording
I introduce the ReactDOMFrameScheduling module which just exposes
rIC and rAF.
The polyfill works by scheduling a requestAnimationFrame, store the time
for the start of the frame, then schedule a postMessage which gets
scheduled after paint. The deadline is set to time + frame rate.
By separating the idle call into a separate event tick we ensure that
layout, paint and other browser work is counted against the available time.
The frame rate is dynamically adjusted by tracking the minimum time between
two rAF callbacks. This is not perfect because browsers can schedule
multiple callbacks to catch up after a long frame. To compensate for this
we only adjust if two consecutive periods are faster than normal.
This seems to guarantee that we will hit frame deadlines and we don't end
up dropping frames. However, there is still some lost time so we risk
starving by not having enough idle time.
Especially Firefox seems to have issues keeping up on the triangle demo
However, that is also true for native rIC in Firefox. It seems like more
render work is scheduled on the main thread pipeline and also that JS
execution just generally has more overhead.
It's not just events that read the current props. Controlled components
do as well. Since we're no longer updating the Fiber pointer during updates
we have to instead read from the node props to get the current props.
Since this method is no longer just used for events I renamed it.
Dan Abramov
Maksim ShastselandDan Abramov
MICHAEL JACKSONandDan Abramov
Zac BraddyandBrian Vaughn
Frank YanandBrandon Dail
Paul O’ShannessyandBrandon Dail
Sebastian MarkbågeandGitHub
Mitchel HumpherysandBrandon Dail
Sebastian Markbage
Brian Vaughn
Andrew ClarkandGitHub
Andrew Clark
jddxfandBrandon Dail
Brandon DailandBrandon Dail
loksonandBrandon Dail
ScottandDan Abramov
Oscar BolmstenandDan Abramov
Edvin EriksonandDan Abramov
Ben AlpertandGitHub
Keyan ZhangandDan Abramov
mguidottoandDan Abramov
OJ KwonandDan Abramov
Justin GrantandDan Abramov
Ragnar Þór ValgeirssonandDan Abramov
SunHuaweiandDan Abramov
Mark PedrottiandDan Abramov