React的理念：
在我们的理念中，React 最初的目的是使用 JavaScript 创建大型的，快速响应的网络应用。它在我们的 Facebook 和 Instagram 中已经实践的非常好了。
然后我来写一个稍微复杂一点的组件吧，来亲自感受一下react的理念：）
我们先从设计师给我们的原型图开始吧：
我们最终就是要弄一个这个东西出来，大概就是一个搜索框，会根据搜索框的内容和单选框的值来筛选结果，然后显示在下面的表格当中。
这个表格的数据假设我们已经有一个接口可以给我们返回数据了，这个接口给我们返回JSON格式的数据，比如：
[
{category: "Sporting Goods", price: "$49.99", stocked: true, name: "Football"},
{category: "Sporting Goods", price: "$9.99", stocked: true, name: "Baseball"},
{category: "Sporting Goods", price: "$29.99", stocked: false, name: "Basketball"},
{category: "Electronics", price: "$99.99", stocked: true, name: "iPod Touch"},
{category: "Electronics", price: "$399.99", stocked: false, name: "iPhone 5"},
{category: "Electronics", price: "$199.99", stocked: true, name: "Nexus 7"}
];
好了，样式和数据都有了，现在到我们来实现了，我们先看看这个大组件的结构。
原型图的设计师们可能已经帮我们划分好了层次结构，他们的photoshop图层的名称可能就是我们所需要划分的组件的名称：）。
那么我们还是需要知道如何划分组件，看看官网的原话：
但你如何知道哪一部分应该成为一个组件？想想在编写代码时你在什么情况下需要新建一个函数或对象，思考方式是一样的。例如单一功能原则，在理想状况下，一个组件应该只做一件事情。如果这个组件功能不断丰富，它应该被分成更小的组件。
既然你经常向用户展示 JSON 数据模型，你会发现，如果你的模型构建正确，你的 UI (以及你的组件结构)会被很好的映射。这是因为 UI 和数据模型往往遵循着相同的信息架构，这意味着将 UI 划分成组件的工作往往是很容易的。只要把它划分成能准确表示你数据模型的一部分的组件就可以。
那么我们分析的结果就是：
-
FilterableProductTable（橙色）：包含所有组件，最大的一个组件
- SearchBar（蓝色）：搜索框以及单选框
-
ProductTable (绿色)：产品列表，按照产品的类别排列产品
- ProductCategoryRow（蓝色）：产品类别（行）
- ProductRow (红色)：产品详情（行）
层级代表了组件的包含关系，这样一分解，就感觉每个组件都很简单，非常好写，我们先写一下静态版本的这些组件，就是不存在状态（state）。我们的渲染需要的数据都通过props传递，每个组件也只有render方法。
我们之前说过react的数据流是从上到下的，是单向数据流（单向绑定）。
codepen代码这是官方实现的代码，我也跟着实现了一遍，发现它有一个地方写的不是很好，就是ProductTable展示产品的时候，因为传入的数据是已经按类别排列好了的，所以它按类别展示部分的逻辑就写的很简单，以致于如果传入的数据不是按顺序排列的话，就会出现错误。
但是我想他这么写也是有一定道理的，因为我们的数据是从后台通过接口得到的，所以可以在后台先把数据处理好，然后传过来，让前端的逻辑尽量简单。
静态的组件完成之后，我们已经可以通过修改传入的商品数据来让商品列表发生变化，来看看我们的UI界面是如何变化的。
接下来我们需要根据输入框和单选框的值来筛选数据，然后显示出来，要做到这个功能，我们需要给输入框和单选框加入state，就像我们之前在表单那一小节中说的那样，让它们变成一个受控组件，但是这样就够了吗？
我们仔细想想这个逻辑，首先我们给SearchBar输入我们想要搜索的名称，然后SearchBar的状态改变，但是我们的最终的结果应该是ProductTable作出相应的变化，所以我们可以看出来，ProductTable是需要SearchBar的状态的，那么我们需要干嘛？
状态提升
对，我们需要把SearchBar的状态提升到SearchBar和ProductTable的父组件上。
接下来就没有什么难度了，大家只要知道了状态提升这招，这个逻辑就很好实现了。
最后给出官方的codepen
