React之智能组件和木偶组件

智能组件 VS 木偶组件

在 React + Redux 结合作为前端框架的时候，提出了一个将组件分为“智能”和“木偶”两种

  • 智能组件：它是数据的所有者，它拥有数据、且拥有操作数据的action，但是它不实现任何具体功能。它会将数据和操作action传递给子组件，让子组件来完成UI或者功能。这就是智能组件，也就是项目中的各个页面。
  • 木偶组件：它就是一个工具，不拥有任何数据、及操作数据的action，给它什么数据它就显示什么数据，给它什么方法，它就调用什么方法，比较傻。这就是木偶组件，即项目中的各个组件。

因此，数据在page层获取、数据的操作和处理在page层定义，组件就是傻傻的知道执行和显示就行了，各操各的心。这种设计也整好符合目前无论是Vue、augular还是React提倡的基于数据驱动的设计理念——程序定义好Model和View的关系，剩下的业余处理只需要关心数据变化，View的变化由框架自动执行，无需像jquery时代再去手动操作DOM。

数据管理

下面看一下数据在系统中是如何传递的。这里的数据分为两种：

  • 第一种可以称之为“系统数据”，和业务无关的，一般任何系统中都会有。例如用户id、用户头像、配置信息等，这个的特点就是符合单例模式，全局共用一套
  • 第二种可以称之为“业务数据”，每个页面都可能不一样。如在娱乐频道需要的是娱乐新闻列表，而到了军事频道就需要军事新闻的列表了，再到新闻详情页就需要新闻的内容了

针对这两种不同的数据，当然要分开处理。针对第一种“系统数据”，系统一初始化就立即获取，然后交给Redux做管理，这也符合Redux的特点。而针对第二种“业务数据”，那就什么时候用，就什么时候获取。

代码架构（物理）

使用React + Redux设计代码结构，目前方式都比较统一，基本都是按照以下方式来设计，这些在github等社区都能找到相似的结构。

app                                // 业务代码目录，或者叫 src
 --actions                        // 定义 Redux 的各个 action
 --components                     // 定义项目中的各个组件，里面可能有很多个子文件夹
 --config                         // 项目配置，无具体规定，自由发挥
 --constants                      // 定义 Redux 中用到的各个常量
 --container                      // 定义项目中的所有的页面
 --fetch                          // 定义项目中所有数据获取、提交的方法
 --reducers                       // 定义 Redux 的 reducer 规则
 --router                         // 定义项目中的 router 规则
 --store                          // 定义 Redux 的全局 store 对象
 --util                           // 工具函数，例如时间格式的处理等
 `--index.jsx                      // 入口，被 ../index.html 引用
resource                           // 静态资源目录，或者叫 static
mocha                              // 测试用例，一般叫 test ，但是使用 fis3 时候 test 文件夹有其他用处，不得不换个名字
.eslintignore
.eslintrc.json
.gitignore
fis-conf.js
index.html
package.json
README.md

以上目录中，app/components和app/container是开发中修改最多的目录。app/container里面定义的都是页面，即智能组件，只关心数据，功能比较单一，因此结构也比较简单

app/container
    list
        index.jsx
        Home.jsx
        Baijia.jsx
    detail
        detail.jsx
        imgDetail.jsx

但是针对组件app/components来说，要显示样式，当然就需要css和图片，文件类型比较多。因此，要按照如下方式定义组件

app/components
    LoadMore
        img
            icon.png
        index.jsx
        style.less
    BannerAd
        img
            close.png
        index.jsx
        style.less

即，用一个文件夹来表示单个组件，里面的index.jsx是业务和模板代码，style.less是样式，img/文件夹放图片文件。这样的话，可以把每个组件都作为一个整体来管理，而且引用的时候也比较方便，例如import LoadMore from '../../app/components/LoadMore'就可以了——目录名即组件的名字。


使用React重构百度新闻webapp前端  https://www.imooc.com/article/12433 

 ————————————————————————————————————————————————————————————————————————

 

Redux 的 React 绑定库包含了 容器组件和展示组件相分离 的开发思想。明智的做法是只在最顶层组件（如路由操作）里使用 Redux。其余内部组件仅仅是展示性的，所有数据都通过 props 传入。

那么为什么需要容器组件和展示组件相分离呢？

这里有个基本原则：容器组件仅仅做数据提取，然后渲染对应的子组件，记住这个点，Trust me！

看下面这个展示列表的例子，不区分容器和展示组件的情况

// CommentList.js
class CommentList extends React.Component {
  constructor() {
    super();
    this.state = { comments: [] }
  }
  componentDidMount() {
    $.ajax({
      url: "/my-comments.json",
      dataType: 'json',
      success: function(comments) {
        this.setState({comments: comments});
      }.bind(this)
    });
  }
  render() {
    return <ul> {this.state.comments.map(renderComment)} </ul>;
  }
  renderComment({body, author}) {
    return <li>{body}—{author}</li>;
  }
}

  • 可用性：CommentList不可以复用

  • 数据结构：组件应该对所需要的数据有所预期，但这里其实没有，PropTypes可以很好的做到这一点

那么来看下分离的情况：

// CommentListContainer.js
class CommentListContainer extends React.Component {
  constructor() {
    super();
    this.state = { comments: [] }
  }
  componentDidMount() {
    $.ajax({
      url: "/my-comments.json",
      dataType: 'json',
      success: function(comments) {
        this.setState({comments: comments});
      }.bind(this)
    });
  }
  render() {
    return <CommentList comments={this.state.comments} />;
  }
}


// CommentList.js
class CommentList extends React.Component {
  constructor(props) {
    super(props);
  }
  render() { 
    return <ul> {this.props.comments.map(renderComment)} </ul>;
  }
  renderComment({body, author}) {
    return <li>{body}—{author}</li>;
  }
}

这样就做到了数据提取和渲染分离，CommentList可以复用，CommentList可以设置PropTypes判断数据的可用性

来看下容器组件和展示组件的区别:

展示组件容器组件
关注事物的展示 关注事物如何工作
可能包含展示和容器组件，并且一般会有DOM标签和css样式 可能包含展示和容器组件，并且不会有DOM标签和css样式
常常允许通过this.props.children传递 提供数据和行为给容器组件或者展示组件
对第三方没有任何依赖，比如store 或者 flux action 调用flux action 并且提供他们的回调给展示组件
不要指定数据如何加载和变化 作为数据源，通常采用较高阶的组件，而不是自己写，比如React Redux的connect(), Relay的createContainer(), Flux Utils的Container.create()
仅通过属性获取数据和回调  
很少有自己的状态，即使有，也是自己的UI状态  
除非他们需要的自己的状态，生命周期，或性能优化才会被写为功能组件  

优势：

  • 展示和容器更好的分离，更好的理解应用程序和UI

  • 重用性高，展示组件可以用于多个不同的state数据源

  • 展示组件就是你的调色板，可以把他们放到单独的页面，在不影响应用程序的情况下，让设计师调整UI

  • 迫使你分离标签，达到更高的可用性

React 之容器组件和展示组件相分离解密  https://segmentfault.com/a/1190000006845396

 

————————————————————————————————————————————————————————————————————————

 

智能组件和木偶组件（也有叫容器组件和UI组件的）。见名知意，智能组件就要做一些比较智能比较‘高端’的工作，智能组件负责逻辑处理、数据获取等比较‘智能’的工作； 
而木偶组件就比较‘呆板’，它原则上只负责展示功能，像一只木偶，别人（智能组件）用线牵着它来控制它的展示内容。

来看一个例子：

class ListUI extends React.Component{
    render(){
        let data = this.props.data;
        return (
            <ul>
                {data.map(item => <li key={item.id} >{item.text}</li>)}
            </ul>
        )
    }
}

class List extends React.Component{
    constructor(){
        super();
        this.getData = this.getData.bind(this);
    }
    render(){
        let data = this.getData();
        return <ListUI data={data} />
    }
    getData(){
        return [{id : 1,text : 'hello'},{id : 2,text : 'world'}];
    }
}

本例中组件List（智能组件）负责获取数据（getData），实际开发中会比这复杂的多，涉及到调用接口获取数据，数据的处理等等，本例侧重说明概念，具体的就不再赘述。 
而组件ListUI（木偶组件）则只负责数据的展示，傻瓜式的别人给他什么他就展示什么。

这是react开发中很重要的一个概念，这种解构分工明确，解构清晰，方便维护和扩展。实属react开发必备之技能。

本例中还有一点值得注意： 
构造函数中的绑定this 实际开发中会在一个组件中定义很多方法，这些方法中可能会有回调函数，这就会导致this指向的问题（当然ES6中的箭头函数能规避这个问题，也推荐只用ES6的写法） 
但是也不排除有ES5的写法存在，所以需要我们绑定this，这里强烈推荐在构造函数中统一的绑定this，这样哪些方法绑定了this就一目了然也便于维护。

基于这个概念做一些扩展。 
事件处理: 有了以上概念的基础，现给组件添加一个点击事件，目的是点击li时弹出当前li的文本内容。根据以上的概念，要把逻辑处理的方法写在智能组件中，然后把方法作为一个prop传递给木偶组件，最后在木偶组件中添加点击事件来调用传过来的方法。 
代码如下：

class ListUI extends React.Component{
    constructor(){
        super();
        this.clickHandler = this.clickHandler.bind(this);
    }
    render(){
        let data = this.props.data;
        return (
            <ul>
                {data.map(item => <li key={item.id} onClick={this.clickHandler}>{item.text}</li>)}
            </ul>
        )
    }
    clickHandler(e){
        this.props.clickHandler(e);
    }
}

class List extends React.Component{
    constructor(){
        super();
        this.getData = this.getData.bind(this);
        this.clickHandler = this.clickHandler.bind(this);
    }
    render(){
        let data = this.getData();
        return <ListUI data={data} click={this.clickHandler}/>
    }
    getData(){
        return [{id : 1,text : 'hello'},{id : 2,text : 'world'}];
    }
    clickHandler(e){
        let ele = e.currentTarget || e.srcElement;
        alert(ele.innerHTML);
    }
}

最后想说的是：智能组件和木偶组件这种编程思想非常重要，开发大型项目时体现的尤为明显，当项目很大时更需要把木偶组件细分，不然代码会杂乱无章，非常的不便于阅读，及其的不利于维护和扩展，最后的结果是项目无法进行。

摘自： https://blog.csdn.net/hkwBest/article/details/78688205?locationNum=6&fps=1 

posted @ 2018-03-30 14:50  無雄  阅读(3091)  评论(0)  编辑  收藏  举报