想知道如何写出漂亮的React组件吗？

在Walmart Labs的产品开发中，我们进行了大量的Code Review工作，这也保证了我有机会从很多优秀的工程师的代码中学习他们的代码风格与样式。在这篇博文里我会分享出我最欣赏的五种组件模式与代码片。不过我首先还是要谈谈为什么我们需要执着于提高代码的阅读体验。就好像你有很多种方式去装扮一只猫，如果你把你的爱猫装扮成了如下这样子:

成都创新互联长期为上千客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为莱阳企业提供专业的网站建设、网站设计，莱阳网站改版等技术服务。拥有10余年丰富建站经验和众多成功案例,为您定制开发。

你或许可以认为萝卜青菜各有所爱，但是代码本身是应当保证其可读性，特别是在一个团队中，你的代码是注定要被其他人阅读的。电脑是不会在意这些的，不管你朝它们扔过去什么，它们都会老老实实的解释，但是你的队友们可不会这样，他们会把丑陋的代码扔回到你的脸上。而所谓的Pretty Components，应该包含如下的特性:

即使没有任何注释的情况下也易于理解
比乱麻般的代码有更好的性能表现
更易于进行Bug追溯
简洁明了，一句顶一万句

[[201978]]

SFC:Stateless Functional Component

我觉得我们在开发中经常忽略掉的一个模式就是所谓的Stateless Functional Component，不过这是我个人***的React组件优化模式，没有之一。我喜爱这种模式不仅仅因为它们能够减少大量的模板代码，而且因为它们能够有效地提高组件的性能表现。总而言之，SFC能够让你的应用跑的更快，长的更帅。

[[201979]]

直观来看，SFC就是指那些仅有一个渲染函数的组件，不过这简单的改变就可以避免很多的无意义的检测与内存分配。下面我们来看一个实践的例子来看下SFC的具体作用，譬如:

如果我们用正统的React组件的写法，可以得出如下代码:

 
 
 
 
  
  
  
  export default class RelatedSearch extends React.Component { 
  
  
  
   
  
  
  
    constructor(props) { 
  
  
  
   
  
  
  
      super(props); 
  
  
  
   
  
  
  
      this._handleClick = this._handleClick.bind(this); 
  
  
  
   
  
  
  
    } 
  
  
  
   
  
  
  
    _handleClick(suggestedUrl, event) { 
  
  
  
   
  
  
  
      event.preventDefault(); 
  
  
  
   
  
  
  
      this.props.onClick(suggestedUrl); 
  
  
  
   
  
  
  
    } 
  
  
  
   
  
  
  
    render() { 
  
  
  
   
  
  
  
      return ( 
  
  
  
   
  
  
  
         
  
  
  
   
  
  
  
          Related Searches: 
  
  
  
   
  
  
  
           
  
  
  
   
  
  
  
            {this.props.relatedQueries.map((query, index) => 
  
  
  
   
  
  
  
              
  
  
  
  
 
  
  
  
                className="related-search-link" 
  
  
  
   
  
  
  
                onClick={(event) => 
  
  
  
   
  
  
  
                  this._handleClick(query.searchQuery, event)} 
  
  
  
   
  
  
  
                key={index}> 
  
  
  
   
  
  
  
                {query.searchText} 
  
  
  
   
  
  
  
               
  
  
  
   
  
  
  
            )} 
  
  
  
   
  
  
  
           
  
  
  
   
  
  
  
         
  
  
  
   
  
  
  
      ); 
  
  
  
   
  
  
  
    } 
  
  
  
   
  
  
  
  }

而使用SFC模式的话，大概可以省下29%的代码:

 
 
 
 
  
  
  
  const _handleClick(suggestedUrl, onClick, event) => { 
  
  
  
   
  
  
  
    event.preventDefault(); 
  
  
  
   
  
  
  
    onClick(suggestedUrl); 
  
  
  
   
  
  
  
  }; 
  
  
  
   
  
  
  
  const RelatedSearch = ({ relatedQueries, onClick }) => 
  
  
  
   
  
  
  
     
  
  
  
   
  
  
  
      Related Searches: 
  
  
  
   
  
  
  
       
  
  
  
   
  
  
  
        {relatedQueries.map((query, index) => 
  
  
  
   
  
  
  
          
  
  
  
  
 
  
  
  
            className="related-search-link" 
  
  
  
   
  
  
  
            onClick={(event) => 
  
  
  
   
  
  
  
              _handleClick(query.searchQuery, onClick, event)} 
  
  
  
   
  
  
  
            key={index}> 
  
  
  
   
  
  
  
            {query.searchText} 
  
  
  
   
  
  
  
           
  
  
  
   
  
  
  
        )} 
  
  
  
   
  
  
  
       
  
  
  
   
  
  
  
     
  
  
  
   
  
  
  
  export default RelatedSearch;

代码量的减少主要来源两个方面:

没有构造函数(5行)
以Arrow Function的方式替代Render语句(4行)

实际上，SFC最迷人的地方不仅仅是其代码量的减少，还有就是对于可读性的提高。SFC模式本身就是所谓纯组件的一种***实践范式，而移除了构造函数并且将_handleClick()这个点击事件回调函数提取出组件外，可以使JSX代码变得更加纯粹。另一个不错的地方就是SFC以Arrow Function的方式来定义了输入的Props变量，即以Object Destructring语法来声明组件所依赖的Props:

 
 
 
 
  
  
  
  const RelatedSearch = ({ relatedQueries, onClick }) =>

这样不仅能够使组件的Props更加清晰明确，还能够避免冗余的this.props表达式，从而使代码的可读性更好。

[[201980]]

***，我还想要强调下虽然我很推崇SFC，不过也不能滥用它。最合适使用SFC的地方就是之前你用纯组件的地方。在Walmart Labs中，我们使用Redux来管理应用的状态，也就意味着我们绝大部分的组件都是纯组件，也就给了SFC广阔的应用空间。一般来说，有以下特征的组件式绝对不适合使用SFC的:

需要自定义整个组件的生命周期管理
需要使用到refs

Conditional Components

JSX本身不支持if表达式，不过我们可以使用逻辑表达式的方式来避免将代码切分到不同的子模块中，大概是如下样子:

 
 
 
 
  
  
  
  render() { 
  
  
  
   
  
  
  
     
  
  
  
   
  
  
  
      {this.props.isGrid 
  
  
  
   
  
  
  
        ?  
  
  
  
   
  
  
  
        : }

}

这种表达式在二选一渲染的时候很有效果，不过对于选择性渲染一个的情况很不友好，譬如如下的情况:

 
 
 
 
  
  
  
  render() { 
  
  
  
   
  
  
  
     
  
  
  
   
  
  
  
      {this.props.isSoftSort 
  
  
  
   
  
  
  
        ?  
  
  
  
   
  
  
  
        : null 
  
  
  
   
  
  
  
      }

这样子确实能起作用，不过看上去感觉怪怪的。我们可以选用另一种更加语义化与友好的方式来实现这个功能，即使用逻辑与表达式然后返回组件:

const SoftSort = ({ hardSortUrl, sortByName, onClick }) => {
return (
Showing results sorted by both Relevance and {sortByName}.
href={`?${hardSortUrl}`}
onClick={(ev) => onClick(ev, hardSortUrl)}>
Sort results by {sortByName} only
);
};

const SoftSort = ({ hardSortUrl, sortByName, onClick }) =>
Showing results sorted by both Relevance and {sortByName}.
href={`?${hardSortUrl}`}
onClick={(ev) => onClick(ev, hardSortUrl)}>
Sort results by {sortByName} only

const mapStateToProps = ({isLoading}) => {
return ({
loading: isLoading,
});
};

render() {
return (
hidePriceFulfillmentDisplay=
{this.props.hidePriceFulfillmentDisplay}
primaryOffer={this.props.primaryOffer}
productType={this.props.productType}
productPageUrl={this.props.productPageUrl}
inventory={this.props.inventory}
submapType={this.props.submapType}
ppu={this.props.ppu}
isLoggedIn={this.props.isLoggedIn}
gridView={this.props.isGridView}
/>
);
}

render() {
const {
hidePriceFulfillmentDisplay,
primaryOffer,
productType,
productPageUrl,
inventory,
submapType,
ppu,
isLoggedIn,
gridView
} = this.props;
return (
hidePriceFulfillmentDisplay={hidePriceFulfillmentDisplay}
primaryOffer={primaryOffer}
productType={productType}
productPageUrl={productPageUrl}
inventory={inventory}
submapType={submapType}
ppu={ppu}
isLoggedIn={isLoggedIn}
gridView={isGridView}
/>
);
}