Commit Graph

6 Commits

Author SHA1 Message Date
Andrew Clark
87ae211ccd New context API (#11818)
* New context API

Introduces a declarative context API that propagates updates even when
shouldComponentUpdate returns false.

* Fuzz tester for context

* Use ReactElement for provider and consumer children

* Unify more branches in createFiberFromElement

* Compare context values using Object.is

Same semantics as PureComponent/shallowEqual.

* Add support for Provider and Consumer to server-side renderer

* Store providers on global stack

Rather than using a linked list stored on the context type. The global
stack can be reset in case of an interruption or error, whereas with the
linked list implementation, you'd need to keep track of every
context type.

* Put new context API behind a feature flag

We'll enable this in www only for now.

* Store nearest provider on context object

* Handle reentrancy in server renderer

Context stack should be per server renderer instance.

* Bailout of consumer updates using bitmask

The context type defines an optional function that compares two context
values, returning a bitfield. A consumer may specify the bits it needs
for rendering. If a provider's context changes, and the consumer's bits
do not intersect with the changed bits, we can skip the consumer.

This is similar to how selectors are used in Redux but fast enough to do
while scanning the tree. The only user code involved is the function
that computes the changed bits. But that's only called once per provider
update, not for every consumer.

* Store current value and changed bits on context object

There are fewer providers than consumers, so better to do this work
at the provider.

* Use maximum of 31 bits for bitmask

This is the largest integer size in V8 on 32-bit systems. Warn in
development if too large a number is used.

* ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer

* Inline Object.is

* Warn if multiple renderers concurrently render the same context provider

Let's see if we can get away with not supporting this for now. If it
turns out that it's needed, we can fall back to backtracking the
fiber return path.

* Nits that came up during review
2018-01-24 19:36:22 -08:00
Andrew Clark
b77b12311f Call and Return components should use ReactElement (#11834)
* Call and Return components should use ReactElement

ReactChildFiber contains lots of branches that do the same thing for
different child types. We can unify them by having more child types be
ReactElements. This requires that the `type` and `key` fields are
sufficient to determine the identity of the child.

The main benefit is decreased file size, especially as we add more
component types, like context providers and consumers.

This updates Call and Return components to use ReactElement. Portals are
left alone for now because their identity includes the host instance.

* Move server render invariant for call and return types

* Sort ReactElement type checks by most likely

* Performance timeline should skip over call components

Don't think these were intentionally omitted from the blacklist of
component types.

I went ahead and updated getComponentName to include special types, even
though I don't think they're used anywhere right now.

* Remove surrounding brackets from internal display names
2017-12-12 15:04:40 -08:00
Brian Vaughn
3322f6bf31 Re-add haste modules for ReactTypes and ReactNativeRTTypes shims (#11557)
* Re-add haste module for ReactNativeRTTypes

* Re-added ReactTypes @providesModule annotation as well

* Updated expected provides modules list

* Improved clarity of check_modules.sh error message

* Added ReactTypes to provides module whitelist
2017-11-15 08:17:15 -08:00
Dan Abramov
45c1ff348e Remove unnecessary 'use strict' in the source (#11433)
* Remove use strict from ES modules

* Delete unused file

This was unused since Stack.
2017-11-02 20:32:48 +00:00
Dan Abramov
2c0a8fb99e Add react-call-return package (#11364) 2017-10-25 22:23:55 +03:00
Dan Abramov
1eed302d34 Drop Haste (#11303)
* Use relative paths in packages/react

* Use relative paths in packages/react-art

* Use relative paths in packages/react-cs

* Use relative paths in other packages

* Fix as many issues as I can

This uncovered an interesting problem where ./b from package/src/a would resolve to a different instantiation of package/src/b in Jest.

Either this is a showstopper or we can solve it by completely fobbidding remaining /src/.

* Fix all tests

It seems we can't use relative requires in tests anymore. Otherwise Jest becomes confused between real file and symlink.
https://github.com/facebook/jest/issues/3830

This seems bad... Except that we already *don't* want people to create tests that import individual source files.
All existing cases of us doing so are actually TODOs waiting to be fixed.

So perhaps this requirement isn't too bad because it makes bad code looks bad.

Of course, if we go with this, we'll have to lint against relative requires in tests.
It also makes moving things more painful.

* Prettier

* Remove @providesModule

* Fix remaining Haste imports I missed earlier

* Fix up paths to reflect new flat structure

* Fix Flow

* Fix CJS and UMD builds

* Fix FB bundles

* Fix RN bundles

* Prettier

* Fix lint

* Fix warning printing and error codes

* Fix buggy return

* Fix lint and Flow

* Use Yarn on CI

* Unbreak Jest

* Fix lint

* Fix aliased originals getting included in DEV

Shouldn't affect correctness (they were ignored) but fixes DEV size regression.

* Record sizes

* Fix weird version in package.json

* Tweak bundle labels

* Get rid of output option by introducing react-dom/server.node

* Reconciler should depend on prop-types

* Update sizes last time
2017-10-25 02:55:00 +03:00