4c3470eef8
* Harden tests around init/addition/update/removal of aliased attributes I noticed some patterns weren't being tested. * Call setValueForProperty() for null and undefined The branching before the call is unnecessary because setValueForProperty() already has an internal branch that delegates to deleteValueForProperty() for null and undefined through the shouldIgnoreValue() check. The goal is to start unifying these methods because their separation doesn't reflect the current behavior (e.g. for unknown properties) anymore, and obscures what actually happens with different inputs. * Inline deleteValueForProperty() into setValueForProperty() Now we don't read propertyInfo twice in this case. I also dropped a few early returns. I added them a while ago when we had Stack-only tracking of DOM operations, and some operations were being counted twice because of how this code is structured. This isn't a problem anymore (both because we don't track operations, and because I've just inlined this method call). * Inline deleteValueForAttribute() into setValueForAttribute() The special cases for null and undefined already exist in setValueForAttribute(). * Delete some dead code * Make setValueForAttribute() a branch of setValueForProperty() Their naming is pretty confusing by now. For example setValueForProperty() calls setValueForAttribute() when shouldSetAttribute() is false (!). I want to refactor (as in, inline and then maybe factor it out differently) the relation between them. For now, I'm consolidating the callers to use setValueForProperty(). * Make it more obvious where we skip and when we reset attributes The naming of these methods is still very vague and conflicting in some cases. Will need further work. * Rewrite setValueForProperty() with early exits This makes the flow clearer in my opinion. * Move shouldIgnoreValue() into DOMProperty It was previously duplicated. It's also suspiciously similar in purpose to shouldTreatAttributeValueAsNull() so I want to see if there is a way to unify them. * Use more specific methods for testing validity * Unify shouldTreatAttributeValueAsNull() and shouldIgnoreValue() * Remove shouldSetAttribute() Its naming was confusing and it was used all over the place instead of more specific checks. Now that we only have one call site, we might as well inline and get rid of it. * Remove unnecessary condition * Remove another unnecessary condition * Add Flow coverage * Oops * Fix lint (ESLint complains about Flow suppression) * Fix treatment of Symbol/Function values on boolean attributes They weren't being properly skipped because of the early return. I added tests for this case. * Avoid getPropertyInfo() calls I think this PR looks worse on benchmarks because we have to read propertyInfo in different places. Originally I tried to get rid of propertyInfo, but looks like it's important for performance after all. So now I'm going into the opposite direction, and precompute propertyInfo as early as possible, and then just pass it around. This way we can avoid extra lookups but keep functions nice and modular. * Pass propertyInfo as argument to getValueForProperty() It always exists because this function is only called for known properties. * Make it clearer this branch is boolean-specific I wrote this and then got confused myself. * Memoize whether propertyInfo accepts boolean value Since we run these checks for all booleans, might as well remember it. * Fix a crash when numeric property is given a Symbol * Record attribute table The changes reflect that SSR doesn't crash with symbols anymore (and just warns, consistently with the client). * Refactor attribute initialization Instead of using flags, explicitly group similar attributes/properties. * Optimization: we know built-in attributes are never invalid * Use strict comparison * Rename methods for clarity * Lint nit * Minor tweaks * Document all the different attribute types
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.
Documentation
You can find the React documentation on the website.
It is divided into several sections:
You can improve it by sending pull requests to this repository.
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. We recommend using Babel with a React preset to convert JSX into native JavaScript for browsers to digest.
Installation
React is available as the react package on npm. It is also available on a CDN.
React is flexible and can be used in a variety of projects. You can create new apps with it, but you can also gradually introduce it into an existing codebase without doing a rewrite.
The recommended way to install React depends on your project. Here you can find short guides for the most common scenarios:
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 Issues
To help you get your feet wet and get you familiar with our contribution process, we have a list of good first issues that contain bugs which have a relatively limited scope. This is a great place to get started.
License
React is MIT licensed.