This is to make sure we don't end up with differences in our different
testing methods. We may switch out the failure allowances later (maybe
just jest will be good enough and we can let phantom fail for a little
bit).
It's possible to configure Jest to not dump the module cache between
specs. This makes it tricky when we silence warnings one a 2nd call.
In this case, the same message was getting logged so when we expected
the count of warning calls to increment, it didn't.
This makes it more difficult to find bugs in mixins both dynamically
and using a static type system.
We also don't have a way to find these to be upgraded to a new mixin
syntax if we needed to.
This hook is currently an optional noop but could be made required to
create a mixin class.
We freed up this internal name by removing the internal base class.
We're now free to use this name as it was intended.
ReactDOMComponent and ReactCompositeComponent are still confusing as
they're internal but we'll rename them later.
All entry points are for reconciliation are within batching strategies.
Since we don't have any batching strategies with synchronous updates,
there can't be more than one life-cycle method on the stack at any given
time.
Therefore, it's safe to move the composite life cycle flag to a singleton.
This saves us some memory management.
I think that we can get rid of these life cycle states completely in the
future.
Currently, the first setState that happens during initial render will
start a new batch. Any subsequent updates will be batched. That means that
the first setState is synchronous but any subsequent setStates are
asynchronous.
This commit makes it so that the batching starts at the root. That way all
the setStates that happen within life-cycle methods are asynchronous.
I originally did this work so that we could allow setState to be called
before the internal ReactCompositeComponent was constructed. It's unlikely
that we'll go down that route now but this still seems like a better
abstraction. It communicates that this is not immediately updating an
object oriented class. It's just a queue which a minor optimization.
It also avoids bloating the ReactCompositeComponent file.
Since they both depend on the life cycle I break that out into a common
shared dependency. In a follow up I'll refactor the life-cycle management.
We need to move instantiation into the mount phase for context purposes.
To do this I moved the shallow rendering stuff into ReactTestUtils and
reused more of the existing code for it by instantiating a noop child.
Everywhere we refer to the "type" we should pass it to ReactNativeComponent
to resolve any string value into the underlying composite.
As part of the new class effort it is now possible to define React
Components using any type of generic JavaScript class syntax.
This includes TypeScript classes. This test ensures that we don't regress
that support, and also serves as an example for using React in TypeScript.
TypeScript provides a good demo of where we think property initializers
are going.
We don't have any official *type* support for TypeScript yet.
This test trails the ReactES6Class-test file. Some manual tweaking is
required when converting tests.
This adds a matcher called toEqualSpecsIn which executes two test suites,
without reporting the result. It then compares the specs and the number
of expects executed by each spec.
This will be used to ensure that tests written in other languages test the
same thing as the base line, ES6 classes.
Sets up CoffeeScript equivalence test.
