* Print a warning in fiber for lacking render method
* Reject initial non-object state in Fiber
Rejects Arrays, Strings & Numbers. Allows nulls.
* Centralize fiber checks on ES6 Classes
* Add classic & instance property checks on fiber
- check the absence of getInitialState & getDefaultProps as methods
- check the absence of propTypes & contextTypes at instance-level
* Convert to normalized React `warning` calls
* Support lifecycle typo detection in fiber
* Get the complete warnings from the existing code
* Only check classInstance once
Avoid rechecking while resuming
* Can warn component while resuming but only once
This is achieved by tracking the warning state in the Fiber structure.
* Remove warning deduplication
* Factor name retrieval in a getName helper
* Use invariant instead of throw
* Read inst.state only once for the invariant
* Fix condition on the instance state
* Register failing/passing fiber tests
* Check if textContent should be set for textarea
shouldSetNodeTextContent returns whether a node.textContent should be
updated. Currently it only covers one case, which is to avoid setting
the textContent if the text is empty and a placeholder exists.
* Only set node.value if it's equal to initialValue
In IE11 textContent is populated when the placeholder attribute is set.
Without this check, we end up setting node.value equal to the
placeholder text, causing the textarea to actually render with the text
inside.
This check makes sure that textContent is equal to our expected
initialValue, which should be the case when using defaultValue.
* Remove placeholder/textarea check, use contentToUse instead
* Refactor scheduling functions and introduce Task priority
There was lots of duplication across all the scheduling functions. I
think we're far enough along that we can start trying to clean some
stuff up.
Also introduces a new priority level provisionally called Task priority.
This is for work that completes at the end of the current tick, after
the current batch of work has been committed. It's different from
Synchronous priority, which needs to complete immediately.
A full implementation of Task priority will follow. It will replace
the current batching solution.
* Implement Task priority
Task priority is similar to Synchronous priority. Both are flushed in
the current tick. Synchronous priority is flushed immediately (e.g. sync
work triggered by setState will flush before setState exits), where as
Task is flushed after the current batch of work is committed.
Currently used for batchedUpdates and nested sync updates. Task should
also be used for componentDidUpdate/Mount and error boundary work. I'll
add this in a later commit.
* Make error boundaries use Task Priority
I have all but one error fixed. Not sure how tricky the last one is,
but I'm cautiously optimistic. Pushing to show my current progress.
* Remove recursion from handleErrors
Changed the algorithm of handleErrors a bit to ensure that boundaries
are not revisited once they are acknowledged.
* Add incremental error boundary test
Discovered an edge case: a noop error boundary will break in incremental
mode unless you explicitly schedule an update.
* Refactor error boundaries in Fiber
* Simplify trapError() calls
The existing logic was written before we had a proper error handling system.
* Remove unnecessary flags
* Prevent performTaskWork recursion
* Be stricter about preventing recursion
Before, this code was bailing out after encoutering a null child because it thought it was out of old children. Seen when reconciling [null, <span />, <Image />] with [null, <span />, <Image />] in XUISelector.
This is already where we trap non-bubbling events. We also already branch
on the tag type so we know if it is interactive or not.
This will let us get rid of the didPutListener and willDeleteListener
abstractions.
I use a simple onclick = emptyFunction to avoid the need for a bookkeeping
map.
Covers some bugs I encountered while working on this feature.
Introduces a syncUpdates API to ReactNoop. Is this something we'd want
to expose to the reconciler?
Without this fix, in non-batched mode, the update is scheduled first and
synchronously flushed before the callback is added to the queue. The
callback isn't called until the next flush.
A bit of restructuring so that setState uses whatever the current
priority context is, like top-level render already does.
Renamed defaultPriority to priorityContext, and added a new variable
called defaultPriorityContext. Having two separate variables allows the
default to be changed without interfering with the current context.
This removes an optimization that avoids call update on ReactDOMSelect
twice in an onChange event.
https://github.com/facebook/react/commit/2601b6a0b0c2b0bccaca67fbbfab6987ac5bef30#commitcomment-19643403
None of the other controlled components do this. The only reason to do it
here is because of the loop.
I'd like to remove this because I'd like to remove all the side-effects
that happen in onChange, other than user defined behavior. I'd also like to
get rid of state that track sequences. It is easier if everything is just
diffing.
Alternatively I can store the previous value that we processed and only
reprocess if the value has changed. However, that would requires the array
for multiple values to be immutable and I don't think we enforce that
right now.
In Fiber, I believe that we'll be able to batch both these updates into a
single commit.
Instead of scheduling individual callbacks to asap, we schedule one and
then do all the work in that one.
I'm doing this for architectural refactoring reasons.
Nevertheless, I'm adding a contrived unit test that this fixes. :)
The type of `ReactFiber.Fiber.effectTag` is `TypeOfSideEffect`.
Thus we should assign `ReactTypeOfSideEffect.NoEffect` value instead of
`ReactPriorityLevel.NoWork` even if they are same values.
* Make test more complete
* Add a failing test for scheduling in reverse order
It hangs forever because we don't clear next pointer when unscheduling a root. Therefore, when it's scheduled again, it brings all its previous chain with it, potentially creating a cycle.
* Clear the next pointer when unscheduling a root
Fixes a potential infinite cycle when we reschedule a root.
* Add new tests to Fiber test tracker
This should be safe because we've been warning for this. The LinkedStateMixin is technically exposed on React.addons without a warning but presumably you wouldn't be using it without a valueLink or checkedLink.
I do this primarily to clear up what the custom onChange listeners are doing.
Renamed the final prop type helper to ReactControlledValuePropTypes.
Gets rid of an obsolete word in the documentation for "State and Lifecycle":
"Consider the ticking clock example from the one of the previous sections."
->
"Consider the ticking clock example from one of the previous sections."