* Store list of contexts on the fiber Currently, context can only be read by a special type of component, ContextConsumer. We want to add support to all fibers, including classes and functional components. Each fiber may read from one or more contexts. To enable quick, mono- morphic access of this list, we'll store them on a fiber property. * Context.unstable_read unstable_read can be called anywhere within the render phase. That includes the render method, getDerivedStateFromProps, constructors, functional components, and context consumer render props. If it's called outside the render phase, an error is thrown. * Remove vestigial context cursor Wasn't being used. * Split fiber.expirationTime into two separate fields Currently, the `expirationTime` field represents the pending work of both the fiber itself — including new props, state, and context — and of any updates in that fiber's subtree. This commit adds a second field called `childExpirationTime`. Now `expirationTime` only represents the pending work of the fiber itself. The subtree's pending work is represented by `childExpirationTime`. The biggest advantage is it requires fewer checks to bailout on already finished work. For most types of work, if the `expirationTime` does not match the render expiration time, we can bailout immediately without any further checks. This won't work for fibers that have `shouldComponentUpdate` semantics (class components), for which we still need to check for props and state changes explicitly. * Performance nits Optimize `readContext` for most common case
react-reconciler
This is an experimental package for creating custom React renderers.
Its API is not as stable as that of React, React Native, or React DOM, and does not follow the common versioning scheme.
Use it at your own risk.
API
var Reconciler = require('react-reconciler');
var HostConfig = {
// You'll need to implement some methods here.
// See below for more information and examples.
};
var MyRenderer = Reconciler(HostConfig);
var RendererPublicAPI = {
render(element, container, callback) {
// Call MyRenderer.updateContainer() to schedule changes on the roots.
// See ReactDOM, React Native, or React ART for practical examples.
}
};
module.exports = RendererPublicAPI;
Practical Examples
A "host config" is an object that you need to provide, and that describes how to make something happen in the "host" environment (e.g. DOM, canvas, console, or whatever your rendering target is). It looks like this:
var HostConfig = {
createInstance(type, props) {
// e.g. DOM renderer returns a DOM node
},
// ...
supportsMutation: true, // it works by mutating nodes
appendChild(parent, child) {
// e.g. DOM renderer would call .appendChild() here
},
// ...
};
For an introduction to writing a very simple custom renderer, check out this article series:
The full list of supported methods can be found here. For their signatures, we recommend looking at specific examples below.
The React repository includes several renderers. Each of them has its own host config.
The examples in the React repository are declared a bit differently than a third-party renderer would be. In particular, the HostConfig object mentioned above is never explicitly declared, and instead is a module in our code. However, its exports correspond directly to properties on a HostConfig object you'd need to declare in your code:
- React ART and its host config
- React DOM and its host config
- React Native and its host config
If these links break please file an issue and we’ll fix them. They intentionally link to the latest versions since the API is still evolving. If you have more questions please file an issue and we’ll try to help!