本文將探究 React API 的演變及其背后的心智模型。從 mixins 到 hooks，再到 RSCs，了解整個(gè)過(guò)程中的權(quán)衡。我們將對(duì) React 的過(guò)去、現(xiàn)在和未來(lái)有一個(gè)更清晰的了解，便于深入研究遺留代碼庫(kù)并評(píng)估其他技術(shù)如何采用不同的方法并做出不同的權(quán)衡。

(相關(guān)資料圖)

我們從面向?qū)ο蟮脑O(shè)計(jì)模式在 JS 生態(tài)系統(tǒng)中流行的時(shí)候開(kāi)始，可以在早期的 React API 中看到這種影響。

React.createClassAPI 是創(chuàng)建組件的原始方式。在 Javascript 支持原生類(lèi)語(yǔ)法之前，React 就有自己的類(lèi)表示。Mixins 是一種用于代碼重用的通用 OOP 模式，下面是一個(gè)簡(jiǎn)化的例子：

function ShoppingCart() {  this.items = [];}var orderMixin = {  calculateTotal() {    // 從 this.items 計(jì)算  }  // .. 其他方法}Object.assign(ShoppingCart.prototype, orderMixin)var cart = new ShoppingCart()cart.calculateTotal()

Javascript 不支持多重繼承，因此 mixin 是重用共享行為和擴(kuò)充類(lèi)的一種方式。那該如何在使用 createClass 創(chuàng)建的組件之間共享邏輯呢？Mixins 是一種常用的模式，它可以訪(fǎng)問(wèn)組件的生命周期方法，允許我們組合邏輯、狀態(tài)等：

var SubscriptionMixin = {  getInitialState: function() {    return {      comments: DataSource.getComments()    };  },  // 當(dāng)一個(gè)組件使用多個(gè) mixin 時(shí)，React 會(huì)嘗試合并多個(gè)mixin的生命周期方法，因此每個(gè)都會(huì)被調(diào)用  componentDidMount: function() {    console.log("do something on mount")  },  componentWillUnmount: function() {    console.log("do something on unmount")  },}// 將對(duì)象傳遞給 createClassvar CommentList = React.createClass({  // 在 mixins 屬性下定義它們  mixins: [SubscriptionMixin, AnotherMixin, SomeOtherMixin],  render: function() {    var { comments, ...otherStuff } = this.state    return (      
        {comments.map(function(comment) {          return         })}      
    )  }})

對(duì)于較小的應(yīng)用，這種方式可以正常運(yùn)行。但是，當(dāng) Mixin 應(yīng)用到大型項(xiàng)目時(shí)，它們也有一些缺點(diǎn)：

在感受到這些問(wèn)題的痛苦之后，React 團(tuán)隊(duì)發(fā)布了“Mixins Considered Harmful”，不鼓勵(lì)繼續(xù)使用這種模式。

當(dāng) Javascript 中支持了原生類(lèi)語(yǔ)法后，React 團(tuán)隊(duì)就在 v15.5 中棄用了createClassAPI，支持原生類(lèi)。

在這個(gè)轉(zhuǎn)變過(guò)程中，我們?nèi)匀话凑疹?lèi)和生命周期的思路來(lái)思考，因此沒(méi)有進(jìn)行重大的心智模型轉(zhuǎn)變?，F(xiàn)在可以擴(kuò)展包含生命周期方法的 Reacts Component 類(lèi)：

class MyComponent extends React.Component {  constructor(props) {    // 在組件掛載到 DOM 之前運(yùn)行    // super 指的是父 Component 的構(gòu)造函數(shù)    super(props)  }  componentWillMount() {}  componentDidMount(){}  componentWillUnmount() {}  componentWillUpdate() {}  shouldComponentUpdate() {}  componentWillReceiveProps() {}  getSnapshotBeforeUpdate() {}  componentDidUpdate() {}  render() {}}

考慮到 mixin 的缺陷，我們?cè)撊绾我赃@種編寫(xiě) React 組件的新方式來(lái)共享邏輯和副作用呢？

這時(shí)候，高階組件 (HOC) 就出現(xiàn)了，它的名字來(lái)源于高階函數(shù)的函數(shù)式編程概念。它成為了替代 Mixin 的一種流行方式，并出現(xiàn)在像 Redux 這樣的庫(kù)的 API 中，例如它的connect函數(shù)，用于將組件連接到 Redux 存儲(chǔ)。除此之外，還有 React Router 的withRouter。

// 一個(gè)創(chuàng)建增強(qiáng)組件的函數(shù)，有一些額外的狀態(tài)、行為或 propsconst EnhancedComponent = myHoc(MyComponent);// HOC 的簡(jiǎn)化示例function myHoc(Component) {  return class extends React.Component {    componentDidMount() {      console.log("do stuff")    }    render() {      // 使用一些注入的 props 渲染原始組件      return     }  }}

高階組件對(duì)于在多個(gè)組件之間共享通用行為非常有用。它們使包裝的組件保持解耦和通用性，以便可以重用。然而，HOC 遇到了與 mixin 類(lèi)似的問(wèn)題：

除了這些陷阱之外，過(guò)度使用 HOC 還導(dǎo)致了深度嵌套和復(fù)雜的組件層次結(jié)構(gòu)以及難以調(diào)試的性能問(wèn)題。

render prop 模式作為 HOC 的替代品出現(xiàn)，這種模式由開(kāi)源 API 如 React-Motion 和 downshift 以及構(gòu)建 React Router 的開(kāi)發(fā)人員推廣普及。

  {interpolatingStyle => 
}

主要思想就是將一個(gè)函數(shù)作為props傳遞給組件。然后組件會(huì)在內(nèi)部調(diào)用該函數(shù)，并傳遞數(shù)據(jù)和方法，將控制反轉(zhuǎn)回函數(shù)以繼續(xù)渲染它們想要的內(nèi)容。

與 HOC 不同，組合發(fā)生在 JSX 內(nèi)部的運(yùn)行時(shí)，而不是靜態(tài)模塊范圍內(nèi)。它們沒(méi)有名稱(chēng)沖突，因?yàn)楹苊鞔_知道是從哪里來(lái)的，也更容易進(jìn)行靜態(tài)類(lèi)型檢查。

但是，當(dāng)用作數(shù)據(jù)提供者時(shí)，它們可能會(huì)導(dǎo)致深度嵌套，創(chuàng)建一個(gè)虛假的組件層次結(jié)構(gòu)：

  {user => (          {userPreferences => (                  {project => (                          {issues => (                                  {notifications => (                                          {timeData => (                                                  {teamMembers => (                             (                                // ...                            )}/>                          )}                                              )}                                      )}                              )}                      )}              )}      )}

這時(shí)，通常會(huì)將管理狀態(tài)的組件與渲染 UI 的組件分開(kāi)來(lái)處理。隨著 Hooks 的出現(xiàn)，“容器”和“展示性”組件模式已經(jīng)不再流行。但值得一提的是，這種模式在服務(wù)逇組件中有所復(fù)興。

目前，render props 仍然是創(chuàng)建可組合組件 API 的有效模式。

Hooks 在 React 16.8 版本中成為了官方的重用邏輯的方式，鞏固了將函數(shù)組件作為編寫(xiě)組件的推薦方式。

Hooks 讓在組件中重用和組合邏輯變得更加簡(jiǎn)單明了。相比于類(lèi)組件，在其中封裝并共享邏輯會(huì)更加棘手，因?yàn)樗鼈兛赡芊稚⒃诟鞣N生命周期方法中的不同部分。

深度嵌套的結(jié)構(gòu)可以被簡(jiǎn)化和扁平化。搭配 TypeScript，Hook 也很容易進(jìn)行類(lèi)型化。

function Example() {  const user = useUser();  const userPreferences = useUserPreferences(user);  const project = useProject(user);  const issues = useIssueTracker(project);  const notifications = useNotification(user);  const timeData = useTimeTracker(user);  const teamMembers = useTeamMembers(project);  return (    
      {/* 渲染內(nèi)容 */}    
  );}

使用 Hooks 帶來(lái)了很多好處，它們解決了類(lèi)中的一些問(wèn)題，但也需要付出一定的代價(jià)，下面來(lái)深入了解一下。

從組件消費(fèi)者的角度來(lái)看，類(lèi)組件到函數(shù)組件的轉(zhuǎn)變并沒(méi)有改變渲染 JSX 的方式。不過(guò)兩種方式的思想是不同的：

return (                                )

// 在服務(wù)器組件內(nèi)部// 允許客戶(hù)端引用和調(diào)用這個(gè)函數(shù)// 不發(fā)送給客戶(hù)端// server (RSC) -> client (RPC) -> server (Action)async function update(formData: FormData) {  "use server"  await db.post.update({    content: formData.get("content"),  })}

// 可以想象可共享的全棧組件// 封裝了服務(wù)端和客戶(hù)端的細(xì)節(jié)}>