揭秘 React 真谛：组件设计

组件不是 React 特有的概念，但是 React 将组件化的思想发扬光大，可谓用到了极致。良好的组件设计会是良好的应用开发基础，这一讲就让我们谈一谈组件设计的奥秘。

单一职责没那么简单

单一职责我们并不陌生，原则上讲，组件只应该做一件事情。但是对于应用来说，全部组件都拆散，只有单一职责并没有必要，反而增加了编写的繁琐程度。那什么时候需要拆分组件，保证单一职责呢？我认为如果一个功能集合有可能发生变化，那么就需要最大程度地保证单一职责。

单一职责带来的最大好处就是在修改组件时，能够做到全在掌控下，不必担心对其他组件造成影响。举个例子：我们的组件需要通过网络请求获取数据并展示数据内容，这样一来潜在的功能集合改变就有：

请求 API 地址发生变化
请求返回数据格式变化
开发者想更换网络请求第三方库，比如 jQuery.ajax 改成 axios
更改请求数据逻辑

再看一个例子：我们需要一个 table 组件，渲染一个 list，那么潜在更改的可能有：

限制一次性渲染的 item 个数（只渲染前 10 个，剩下的懒加载）
当数据列表为空时显示 “This list is empty”
任何渲染逻辑的更改

这个图很好地说明了问题：

我们来实际看一个场景：

import axios from 'axios'

class Weather extends Component {  
  constructor(props) {
    super(props)
    this.state = { temperature: 'N/A', windSpeed: 'N/A' }
  }

  componentDidMount() {
    axios.get('http://weather.com/api').then(response => {
      const { current } = response.data
      this.setState({
        temperature: current.temperature,
        windSpeed: current.windSpeed
      })
    })
  }

  render() {
    const { temperature, windSpeed } = this.state
    return (
      <div className="weather">
        <div>Temperature: {temperature} °C</div>
        <div>Wind: {windSpeed} km/h</div>
      </div>
    )
  }
}

这个组件很容易理解，并且看上去没什么大问题，但是并不符合单一职责。比如这个 Weather 组件将数据获取与渲染逻辑耦合在一起，如果数据请求有变化，就需要在 componentDidMount 生命周期中进行改动；如果展示天气的逻辑有变化，render 方法又需要变动。

如果我们将这个组件拆分成：WeatherFetch 和 WeatherInfo 两个组件，这两个组件各自只做一件事情，保持单一职责：

import axios from 'axios'
import WeatherInfo from './weatherInfo'

class WeatherFetch extends Component {  
  constructor(props) {
    super(props)
    this.state = { temperature: 'N/A', windSpeed: 'N/A' }
  }

  componentDidMount() {
    axios.get('http://weather.com/api').then(response => {
      const { current } = response.data
      this.setState({
        temperature: current.temperature,
        windSpeed: current.windSpeed
        })
      })
  }

  render() {
    const { temperature, windSpeed } = this.state
    return (
      <WeatherInfo temperature={temperature} windSpeed={windSpeed} />
    )
  }
}

另一个文件中：

const WeatherInfo = ({ temperature, windSpeed }) => 
  (
    <div className="weather">
      <div>Temperature: {temperature} °C</div>
      <div>Wind: {windSpeed} km/h</div>
    </div>
  )

如果我们想进行重构，使用 async/await 代替 Promise，只需要直接更改 WeatherFetch 组件：

class WeatherFetch extends Component {  
  // ...

  async componentDidMount() {
    const response = await axios.get('http://weather.com/api')
    const { current } = response.data

    this.setState({
      temperature: current.temperature,
      windSpeed: current.windSpeed
      })
    })
  }

  // ...
}

而不会对 WeatherInfo 组件有任何影响。

或者显示风速的逻辑从 Wind: 0 km/h 改为文字描述 Wind: 风平浪静，也只需要改动 WeatherInfo：

const WeatherInfo = ({ temperature, windSpeed }) => {
  const windInfo = windSpeed === 0 ? 'calm' : `${windSpeed} km/h`
  return (
    <div className="weather">
      <div>Temperature: {temperature} °C</div>
      <div>Wind: {windSpeed} km/h</div>
    </div>
  )
}

这只是一个简单的例子，在真实项目中，保持组件的单一职责将会非常重要，甚至我们可以使用 HoC 强制组件的单一职责性。

来思考这样的代码：

class PersistentForm extends Component {  
  constructor(props) {
    super(props)
    this.state = { inputValue: localStorage.getItem('inputValue') }
    this.handleChange = this.handleChange.bind(this)
    this.handleClick = this.handleClick.bind(this)
  }

  handleChange(event) {
    this.setState({
      inputValue: event.target.value
    })
  }

  handleClick() {
    localStorage.setItem('inputValue', this.state.inputValue)
  }

  render() {
    const { inputValue } = this.state
    return (
      <div className="persistent-form">
        <input type="text" value={inputValue} 
          onChange={this.handleChange}
        /> 
        <button onClick={this.handleClick}>
          Save to storage
        </button>
      </div>
    )
  }
}

这是一个持久化存储的表单，我们将表单字段内容存储在 localStorage 中，这样不管是刷新页面还是重新进入页面，都会保存上一次点击提交时的内容。可惜 PersistentForm 组件也是包含了两部分职责：存储内容和渲染内容。

这次我们的重构不再是简单的拆分组件，而是使用 HoC 来完成职责单一的实现：

class PersistentForm extends Component {  
  constructor(props) {
    super(props)
    this.state = { inputValue: props.initialValue }
    this.handleChange = this.handleChange.bind(this)
    this.handleClick = this.handleClick.bind(this)
  }

  handleChange(event) {
    this.setState({
      inputValue: event.target.value
    })
  }

  handleClick() {
    this.props.saveValue(this.state.inputValue)
  }

  render() {
    const { inputValue } = this.state
    return (
      <div className="persistent-form">
        <input type="text" value={inputValue} 
          onChange={this.handleChange}
        /> 
        <button onClick={this.handleClick}>
          Save to storage
        </button>
      </div>
    )
  }
}

我们只是改变了两行代码，初始 state 不再直接读取 localStorage，而是由 this.props.initialValue 提供；handleClick 逻辑调用 this.props.saveValue，而不再直接操作 localStorage，this.props.saveValue 将会由 withPersistence 这个 HoC 提供：

function withPersistence(storageKey, storage) {  
  return function(WrappedComponent) {
    return class PersistentComponent extends Component {
      constructor(props) {
        super(props)
        this.state = { initialValue: storage.getItem(storageKey) }
      }

      render() {
         return (
           <WrappedComponent
             initialValue={this.state.initialValue}
             saveValue={this.saveValue}
             {...this.props}
           />
         );
      }

      saveValue(value) {
        storage.setItem(storageKey, value)
      }
    }
  }
}

使用方式：

const LocalStoragePersistentForm  
  = withPersistence('key', localStorage)(PersistentForm)

这种方式是组件单一职责和组件复用的结合体现，其他组件当然也可以使用这个 HoC:

const LocalStorageMyOtherForm  
  = withPersistence('key', localStorage)(MyOtherForm)

存储和渲染职责解耦，我们便可以随时切换存储方式，比如切换为 sessionStorage 代替 localStorage：

const SessionStoragePersistentForm  
  = withPersistence('key', sessionStorage)(PersistentForm)

组件通信和封装

另一个和组件职责单一相关的话题是组件的封装，封装又涉及到组件间的通信。因为我们知道，组件再封装，还是要和其他组件去交互通信的，那么当我们说封装时在说些什么呢？

组件关联有紧耦合和松耦合之分，紧耦合是指两个或多个组件之间需要了解彼此的组件内设计，这样的情况是我们不想看到的，这破坏了组件的独立性，“牵一发动全身”。这么看来，松耦合带来的好处是很直接的：

一处组件的改动完全独立，不影响其他组件
更好的复用设计
更好的可测试性

我们直接来看场景代码，一个简单的计数器足以说明问题：

class App extends Component {  
  constructor(props) {
    super(props)
    this.state = { number: 0 }
  }

  render() {
    return (
      <div className="app"> 
        <span className="number">{this.state.number}</span>
        <Controls parent={this} />
      </div>
    )
  }
}

class Controls extends Component {
  updateNumber(toAdd) {
    this.props.parent.setState(prevState => ({
      number: prevState.number + toAdd       
    }))
  }

  render() {
    return (
      <div className="controls">
        <button onClick={() => this.updateNumber(+1)}>
          Increase
        </button> 
        <button onClick={() => this.updateNumber(-1)}>
          Decrease
        </button>
      </div>
    )
  }
}

这样的组件实现问题很明显：App 组件不具有封装性，它将实例传给 Controls 组件，Controls 组件可以直接更改 App state 的内容。事实上，我们并不是不允许 Controls 组件修改 App 组件，只是 Controls 组件直接调用 App 组件的 setState 方法是不被建议的，因为 Controls 组件如果要调用 App 的 setState，就得需要知道 App 组件 state 的结构，需要感知 this.props.parent.state.number 等详情。

同时上述代码也不利于测试，这个我们将在后面进行说明。那么该如何重构呢？我们应该用更加“含蓄”或者更加“粗暴、直接地”方式修改 number 值。秉承封装性：“只有组件自己知道自己的 state 结构”，将 updateNumber 迁移至 App 组件内：

class App extends Component {  
  constructor(props) {
    super(props)
    this.state = { number: 0 }
  }

  updateNumber(toAdd) {
    this.setState(prevState => ({
      number: prevState.number + toAdd       
    }))
  }

  render() {
    return (
      <div className="app"> 
        <span className="number">{this.state.number}</span>
        <Controls 
          onIncrease={() => this.updateNumber(+1)}
          onDecrease={() => this.updateNumber(-1)} 
        />
      </div>
    )
  }
}


const Controls = ({ onIncrease, onDecrease }) => {  
  return (
    <div className="controls">
      <button onClick={onIncrease}>Increase</button> 
      <button onClick={onDecrease}>Decrease</button>
    </div>
  )
}

这样一来，Controls 组件就不需要再知道 App 组件的内部情况，实现了更好的复用性和可测试性，App 组件因此也具有了更好的封装性。

组合性是灵魂

如果说组件单一职责确定了如何拆分组件，封装性明确了组件如何组织，那么组合性就完成了整个应用的拼接。

React 具有天生的组合基因：

对应声明式代码：

const app = (  
  <Application>
    <Header />
    <Sidebar>
      <Menu />
    </Sidebar>
    <Content>
      <Article />
    </Content>
    <Footer />
  </Application>
)

如果两个组件 Composed1 和 Composed2 具有相同的逻辑，我们可以使用组合性进行拆分重组：

const instance1 = (  
  <Composed1>
      // Composed1 逻辑
      // 重复逻辑
  </Composed1>
)
const instance2 = (  
  <Composed2>
      // 重复逻辑
      // Composed2 逻辑
  </Composed2>
)

重复逻辑提取为 Common 组件：

const instance1 = (  
  <Composed1>
    <Logic1 />
    <Common />
  </Composed1>
)
const instance2 = (  
  <Composed2>
    <Common />
    <Logic2 />
  </Composed2>
)

另外一个典型应用就是 render prop 模式，这个我们前面已经介绍过，这里给出一个很简单的示例，具体不再展开：

const ByDevice = ({ children: { mobile, other } }) => {  
  return Utils.isMobile() ? mobile : other
}

<ByDevice>
    {{  
      mobile: <div>Mobile detected!</div>,
      other:  <div>Not a mobile device</div>
    }}
</ByDevice>

副作用和（准）纯组件

纯函数和非纯函数概念大家并不陌生，简单来说，通过函数参数能够唯一确定函数返回值的函数，我们称之为纯函数，反之就是有副作用的非纯函数。纯/非纯函数延伸到组件中，就是纯/非纯组件。

在理想主义者眼中，最好的情况是应用组件全部由纯组件组成，这样对于组件的调试和强健性非常重要。但这只能是理想情况，在真实环境中，我们需要发送网络请求以获取数据（副作用，因为数据不固定，需要从网络获取），进行条件渲染等操作，如何最大限度地保证纯组件或者（准）纯组件呢？我们先来下一个定义：

（准）纯组件是渲染数据全部来自于 props，但是会产生副作用的组件

从非纯组件中提取纯组件部分，是一个很常见有效的做法。

const globalConfig = {  
  siteName: 'Animals in Zoo'
}

const Header = ({ children }) => {  
  const heading = 
    globalConfig.siteName ? <h1>{globalConfig.siteName}</h1> : null
  return (
     <div>
       {heading}
       {children}
     </div>
  );
}

这个组件是典型的非纯组件，因为它依赖全局变量 siteName，可能渲染出：

Animals in Zoo

Some content Some content

在编写测试用例时，还需要考虑 globalConfig.siteName，使得逻辑更加复杂：

import assert from 'assert'
import { shallow } from 'enzyme'
import { globalConfig } from './config'
import Header from './Header'

describe('<Header />', function() {  
  it('should render the heading', function() {
    const wrapper = shallow(
      <Header>Some content</Header>
    )
    assert(wrapper.contains(<h1>Animals in Zoo</h1>))
  })

  it('should not render the heading', function() {
    // 改动全局变量
    globalConfig.siteName = null
    const wrapper = shallow(
      <Header>Some content</Header>
    )
    assert(appWithHeading.find('h1').length === 0)
  })
})

在测试 Header 组件时，多了一种 case 不说，我们还需要手动改写全局变量的值。

一个常用的优化方式是使全局变量作为 Header 的 props 出现，而不再是一个外部变量，那么函数式组件 Header 就完全依赖其参数：

const Header = ({ children, siteName }) => {  
  const heading = siteName ? <h1>{siteName}</h1> : null;
  return (
     <div className="header">
       {heading}
       {children}
     </div>
  );
}

Header.defaultProps = {  
  siteName: globalConfig.siteName
}

这样一来 Header 就成了纯组件，测试用例便可以简化为：

import assert from 'assert'
import { shallow } from 'enzyme' 
import { Header } from './Header';

describe('<Header />', function() {  
  it('should render the heading', function() {
    const wrapper = shallow(
      <Header siteName="Animals in Zoo">Some content</Header>
    )
    assert(wrapper.contains(<h1>Animals in Zoo</h1>))
  });

  it('should not render the heading', function() {
    const wrapper = shallow(
      <Header siteName={null}>Some content</Header>
    )
    assert(appWithHeading.find('h1').length === 0)
  })
})

且不需再手动改动变量的值，以完成测试逻辑。

另一个重构非纯组件的典型案例就是针对有网络请求的副作用情况，重放我们在组件单一职责中的代码：

import axios from 'axios'
import WeatherInfo from './weatherInfo'

class WeatherFetch extends Component {  
  constructor(props) {
    super(props)
    this.state = { temperature: 'N/A', windSpeed: 'N/A' }
  }

  componentDidMount() {
    axios.get('http://weather.com/api').then(response => {
      const { current } = response.data
      this.setState({
        temperature: current.temperature,
        windSpeed: current.windSpeed
        })
      })
  }

  render() {
    const { temperature, windSpeed } = this.state
    return (
      <WeatherInfo temperature={temperature} windSpeed={windSpeed} />
    )
  }
}

从表面上看，WeatherFetch 组件不得不“非纯”，因为网络请求不可避免，但是我们可以将请求的主体逻辑分离出组件，而组件只负责调用请求，这样的操作我称之为“（准）纯组件”：

import { connect } from 'react-redux' 
import { fetch } from './action'

export class WeatherFetch extends Component {  
   render() {
     const { temperature, windSpeed } = this.props
     return (
       <WeatherInfo temperature={temperature} windSpeed={windSpeed} />
     )
   }

   componentDidMount() {
     this.props.fetch()
   }
}

function mapStateToProps(state) {  
  return {
    temperature: state.temperate,
    windSpeed: state.windSpeed
  }
}

export default connect(mapStateToProps, { fetch })

我们使用 Redux 来完成，这样一来 WeatherFetch 组件至少可以保证“相同的 props，会渲染相同的结果”。测试也就变得可行：

import assert from 'assert'
import { shallow, mount } from 'enzyme'
import { spy } from 'sinon'

import { WeatherFetch } from './WeatherFetch';  
import WeatherInfo from './WeatherInfo'

describe('<WeatherFetch />', function() {  
  it('should render the weather info', function() {
    function noop() {}
    const wrapper = shallow(
      <WeatherFetch temperature="30" windSpeed="10" fetch={noop} />
    )
    assert(wrapper.contains(
      <WeatherInfo temperature="30" windSpeed="10" />
    ))
  });

  it('should fetch weather when mounted', function() {
    const fetchSpy = spy()
    const wrapper = mount(
     <WeatherFetch temperature="30" windSpeed="10" fetch={fetchSpy}/>
    )
    assert(fetchSpy.calledOnce)
  })
})

组件可测试性

我们一直在提“可测试性”，上面也出现了测试用例代码，我认为是否具有测试意识，是区别高级和一般程序员的考证之一。

还记得我们在上面提到的 Controls 组件吗？最初实现：

class App extends Component {  
  constructor(props) {
    super(props)
    this.state = { number: 0 }
  }

  render() {
    return (
      <div className="app"> 
        <span className="number">{this.state.number}</span>
        <Controls parent={this} />
      </div>
    )
  }
}

class Controls extends Component {
  updateNumber(toAdd) {
    this.props.parent.setState(prevState => ({
      number: prevState.number + toAdd       
    }))
  }

  render() {
    return (
      <div className="controls">
        <button onClick={() => this.updateNumber(+1)}>
          Increase
        </button> 
        <button onClick={() => this.updateNumber(-1)}>
          Decrease
        </button>
      </div>
    )
  }
}

因为 Controls 组件的行为完全依赖其父组件，因此为了测试，我们需要临时构造一个父组件 Temp 来完成：

class Temp extends Component {  
  constructor(props) {
    super(props)
    this.state = { number: 0 }
  }
  render() {
    return null
  }
}

describe('<Controls />', function() {  
  it('should update parent state', function() {
    const parent = shallow(<Temp/>)
    const wrapper = shallow(<Controls parent={parent} />)

    assert(parent.state('number') === 0)

    wrapper.find('button').at(0).simulate('click')
    assert(parent.state('number') === 1)

    wrapper.find('button').at(1).simulate('click')
    assert(parent.state('number') === 0)
  });
});

测试编写的非常痛苦，而经过我们重构之后，变的就非常简单了：

class App extends Component {  
  constructor(props) {
    super(props)
    this.state = { number: 0 }
  }

  updateNumber(toAdd) {
    this.setState(prevState => ({
      number: prevState.number + toAdd       
    }))
  }

  render() {
    return (
      <div className="app"> 
        <span className="number">{this.state.number}</span>
        <Controls 
          onIncrease={() => this.updateNumber(+1)}
          onDecrease={() => this.updateNumber(-1)} 
        />
      </div>
    )
  }
}


const Controls = ({ onIncrease, onDecrease }) => {  
  return (
    <div className="controls">
      <button onClick={onIncrease}>Increase</button> 
      <button onClick={onDecrease}>Decrease</button>
    </div>
  )
}

describe('<Controls />', function() {  
  it('should execute callback on buttons click', function() {
    const increase = sinon.spy()
    const descrease = sinon.spy()
    const wrapper = shallow(
      <Controls onIncrease={increase} onDecrease={descrease} />
    )

    wrapper.find('button').at(0).simulate('click')
    assert(increase.calledOnce)
    wrapper.find('button').at(1).simulate('click')
    assert(descrease.calledOnce)
  })
})

有的开发者觉得“测试不重要”，因此也不用关心组件编写的可测试性。其实我认为，之所以会有程序员认为“测试不重要”，是因为他不具有看待项目的更高视野和角度，也没有编写稳定可靠组件库或其他库的经验。我们要端正态度，想要进阶，就要从态度入手，从掌握一门测试用例的使用入手。

组件命名是意识和态度问题

我为什么要把组件命名放在最后一部分呢？因为组件命名太简单了，任何一个开发者只要有意识，能用心，都能完成很好的命名；同时组件命名又太重要了，良好的组件命名就是“行走着的注释”。但意识是一个很虚的概念，有的程序员也许天生就不具备，有的程序员即便具备了，也懒得去琢磨。这里，我不赘述太多道理，读者只需观察两段代码即可，其中第一段，我加了大量的注释辅助：

// <Games> 返回一组 game 信息
// data 是一个数组，包含了所有 game 信息
function Games({ data }) {  
  // 选出前 10 条 games
  const data1 = data.slice(0, 10)
  // list 是包含了 10 条 games 的 Game 组件集合
  const list = data1.map(function(v) {
    // v 代码当前 game
    return <Game key={v.id} name={v.name} />
  })
  return <ul>{list}</ul>
}

<Games  
   data=[{ id: 1, name: 'Mario' }, { id: 2, name: 'Doom' }] 
/>

第二段代码不需要一行注释：

const GAMES_LIMIT = 10

const GamesList = ({ items }) => {  
  const itemsSlice = items.slice(0, GAMES_LIMIT)
  const games = itemsSlice.map(gameItem => 
    <Game key={gameItem.id} name={gameItem.name} />
  )
  return <ul>{games}</ul>
}

<GamesList  
  items=[{ id: 1, name: 'Mario' }, { id: 2, name: 'Doom' }]
/>

组件设计功力，其实一个命名就能看出来；在做 code review 时，一个命名也能出卖你的深浅。

总结

本讲我们剖析了组件设计的基本原则，在原则范畴内，展现了组件的灵活性，并将组件复用性融汇在课程中。其实不光 React 组件如此，任何框架的组件也都是如此，超脱于组件范畴之外，API 设计也应用着相同的原则。这是编程最本质的思想，甚至从某种程度上，在编程之外，原子组建成大千世界的哲学道理都是异曲同工的。

分享交流

在阅读文章过程中有任何疑问可随时跟其他小伙伴讨论，或者直接向作者 LucasHC 提问（作者看到后抽空回复）。 你的分享不仅帮助他人，更会提升自己。

你也可以说说自己最想了解的主题，课程内容会根据部分读者的意见和建议迭代和完善。

此外，我们为本课程付费读者创建了《前端开发核心知识进阶》微信交流群，以方便更有针对性地讨论课程相关问题（入群请到第1-2课末尾添加 GitChat 小助手伽利略的微信，并注明「前端核心」，谢谢~）

Previous你真的懂 React 吗 Next揭秘 React 真谛：数据状态管理

Last updated 3 years ago