c87ffc0beb
* Test that SVG elements get created with the right namespace * Pass root to the renderer methods * Keep track of host instances and containers * Keep instances instead of fibers on the stack * Create text instances in begin phase * Create instance before bailing on offscreen children Otherwise, the parent gets skipped next time. We could probably create it later but this seems simpler. * Tweak magic numbers in incremental tests I don't understand why they changed but probably related to us moving some work into begin phase? * Only push newly created nodes on the parent stack Previously I was pushing nodes on the parent stack regardless of whether they were already in current or not. As a result, insertions during updates were duplicated, and nodes were added to existing parents before commit phase. Luckily we have a test that caught that. * Fix lint * Fix Flow I had to wrap HostContext API into a closure so that it's parameterizeable with I and C. * Use the same destructuring style in scheduler as everywhere else * Remove branches that don't seem to run anymore I'm not 100% sure this is right but I can't get tests to fail. * Be explicit about the difference between type and tag I was confused by th HACK comment so I learned how DOM and SVG work with casing and tried to write a more descriptive comment. It also seems like passing fiber.type into finalizeInitialChildren() is a potential problem because DOM code assumes tag is lowercase. So I added a similar "hack" to finalizeInitialChildren() that is identical to the one we have prepareUpdate() so if we fix them later, we fix both. * Save and restore host context when pushing and popping portals * Revert parent context and adding children in the begin phase We can address this later separately as it is a more hot path. This doesn't affect correctness of SVG container behavior. * Add a test for SVG updates This tests the "jump" reuse code path in particular. * Record tests * Read ownerDocument from the root container instance This way createInstance() depends on the innermost container only for reading the namespace. * Track namespaces instead of creating instances early While we might want to create instance in the begin phase, we shouldn't let DOM guide reconciler design. Instead, we are adding a new concept of "host context". In case of ReactDOMFiber, it's just the current namespace. We are keeping a stack of host context values, ignoring those that are referentially equal. The renderer receives the parent context and type, and can return a new context. * Pop child context before reading own context and clarify API It wasn't quite clear from the API which context was being returned by the renderer. Changed the API to specifically ask for child context, and thus to pop it before getting the current context. This fixes the case with <foreignObject> to which I intended to give SVG namespace. * Give SVG namespace to <svg> itself * Don't allocate unnecessarily when reconciling portals We create stacks lazily so that if portal doesn't contain <svg>s, we don't need to allocate. We also reuse the same object for portal host context state instead of creating a new one every time. * Add more tests for edge cases * Fix up math namespace * Maintain a separate container stack * Fix rebase mistakes * Unwind context on errors * Reset the container state when reusing the object * Add getChildHostContext() to ReactART * Record tests
React · 
React is a JavaScript library for building user interfaces.
- Declarative: React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes. Declarative views make your code more predictable, simpler to understand, and easier to debug.
- Component-Based: Build encapsulated components that manage their own state, then compose them to make complex UIs. Since component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep state out of the DOM.
- Learn Once, Write Anywhere: We don't make assumptions about the rest of your technology stack, so you can develop new features in React without rewriting existing code. React can also render on the server using Node and power mobile apps using React Native.
Learn how to use React in your own project.
Examples
We have several examples on the website. Here is the first one to get you started:
class HelloMessage extends React.Component {
render() {
return <div>Hello {this.props.name}</div>;
}
}
ReactDOM.render(
<HelloMessage name="John" />,
document.getElementById('container')
);
This example will render "Hello John" into a container on the page.
You'll notice that we used an HTML-like syntax; we call it JSX. JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. A simple transform is included with React that allows converting JSX into native JavaScript for browsers to digest.
Installation
The fastest way to get started is to serve JavaScript from a CDN. We're using unpkg below but React is also available on cdnjs and jsdelivr:
<!-- The core React library -->
<script src="https://unpkg.com/react@15.4.0/dist/react.js"></script>
<!-- The ReactDOM Library -->
<script src="https://unpkg.com/react-dom@15.4.0/dist/react-dom.js"></script>
We've also built a starter kit which might be useful if this is your first time using React. It includes a webpage with an example of using React with live code.
If you'd like to use bower, it's as easy as:
bower install --save react
And it's just as easy with npm:
npm i --save react
Contributing
The main purpose of this repository is to continue to evolve React core, making it faster and easier to use. Development of React happens in the open on GitHub, and we are grateful to the community for contributing bugfixes and improvements. Read below to learn how you can take part in improving React.
Code of Conduct
Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.
Contributing Guide
Read our contributing guide to learn about our development process, how to propose bugfixes and improvements, and how to build and test your changes to React.
Good First Bug
To help you get your feet wet and get you familiar with our contribution process, we have a list of good first bugs that contain bugs which are fairly easy to fix. This is a great place to get started.
License
React is BSD licensed. We also provide an additional patent grant.
React documentation is Creative Commons licensed.
Examples provided in this repository and in the documentation are separately licensed.
Troubleshooting
See the Troubleshooting Guide