React note

note React

---

concept

browser suppoerted

suppoert ie>=8,but IE8 not support onscroll

render

Remember, what you return from render() is not your actual rendered children instances. What you return from render() is merely a description of the children instances in your component's sub-hierarchy at a particular moment in time.

props

<SearchBar
    filterText={this.state.filterText}
    inStockOnly={this.state.inStockOnly}
    onUserInput={this.handleUserInput}
/>
this.props.filterText ==>filterText

state

by getInitialState init state variable
==> getInitialState: function() {
return {
filterText: '',
inStockOnly: false
};
},
reset state variable
==> this.setState({
filterText: filterText,
inStockOnly: inStockOnly
});

ref the state variable
this.state.inStockOnly ==>inStockOnly

ref

Refs are a great way to send a message to a particular child instance in a way that would be inconvenient to do via streaming Reactive props and state. They should, however, not be your go-to abstraction for flowing data through your application. By default, use the Reactive data flow and save refs for use cases that are inherently non-reactive.

key:

an optional, unique identifier. When your component shuffles around during render passes, it might be destroyed and recreated due to the diff algorithm. Assigning it a key that persists makes sure the component stays. See more here.

dangerouslySetInnerHTML:

takes an object with the key __html and a DOM string as value. This is mainly for cooperating with DOM string manipulation libraries. Refer to the last example on the front page.

Benefits:

• You can define any public method on your component classes (such as a reset method on a Typeahead) and call those public methods through refs (such as this.refs.myTypeahead.reset()).
• Performing DOM measurements almost always requires reaching out to a "native" component such as and accessing its underlying DOM node via this.refs.myInput.getDOMNode(). Refs are one of the only practical ways of doing this reliably.
• Refs are automatically book-kept for you! If that child is destroyed, its ref is also destroyed for you. No worrying about memory here (unless you do something crazy to retain a reference yourself).

Cautions: #

• Never access refs inside of any component's render method - or while any component's render method is even running anywhere in the call stack.
• If you want to preserve Google Closure Compiler Crushing resilience, make sure to never access as a property what was specified as a string. This means you must access using this.refs['myRefString'] if your ref was defined as ref="myRefString".
• if you have not programmed several apps with React, your first inclination is usually going to be to try to use refs to "make things happen" in your app. If this is the case, take a moment and think more critically about where state should be owned in the component hierarchy. Often, it becomes clear that the proper place to "own" that state is at a higher level in the hierarchy. Placing the state there often eliminates any desire to use refs to "make things happen" – instead, the data flow will usually accomplish your goal.

Children

<Parent><Child /></Parent>

Parent can read its children by accessing the special this.props.children prop.