摘要：盤點一下，模式反應了典型的控制權問題。異步狀態管理與控制權提到控制權話題，怎能少得了這樣的狀態管理工具。狀態管理中的控制主義和極簡主義了解了異步狀態中的控制權問題，我們再從全局角度進行分析。

控制權——這個概念在編程中至關重要。比如，“輪子”封裝層與業務消費層對于控制權的“爭奪”，就是一個很有意思的話題。這在 React 世界里也不例外。表面上看，我們當然希望“輪子”掌控的事情越多越好：因為抽象層處理的邏輯越多，業務調用時關心的事情就越少，使用就越方便。可是有些設計卻“不敢越雷池一步”。“輪子”與業務在控制權上的拉鋸，就非常有意思了。

同時，控制能力與組件設計也息息相關：Atomic components 這樣的原子組件設計被受推崇；在原子組件這個概念之上，還有分子組件：Molecules components。不管是分子還是原子，在解決業務問題上都有存在的理由。

這篇文章將以 React 框架為背景，談談我在開發當中對于控制權的一些想法和總結。如果你并不使用 React，原則上仍不妨礙閱讀。

在文章開始之前，我想先向大家介紹一本書。

從去年起，我和知名技術大佬顏海鏡開始了合著之旅，今年我們共同打磨的書籍《React 狀態管理與同構實戰》終于正式出版了！這本書以 React 技術棧為核心，在介紹 React 用法的基礎上，從源碼層面分析了 Redux 思想，同時著重介紹了服務端渲染和同構應用的架構模式。書中包含許多項目實例，不僅為用戶打開了 React 技術棧的大門，更能提升讀者對前沿領域的整體認知。

如果各位對圖書內容或接下來的內容感興趣，還望多多支持！文末有詳情，不要走開！

初入 React 大門，關于控制權概念，我們最先接觸到的就是受控組件與非受控組件。這兩個概念往往與表單關聯在一起。在大部分情況下，推薦使用受控組件來實現表單、輸入框等狀態控制。在受控組件中，表單等數據都由 React 組件自己處理。而非受控組件，是指表單的數據由 Dom 自己控制。下面就是一個典型的非受控組件：

  
    Name:
    
  
  

對于 React 來說，非受控組件的狀態和用戶輸入都無法直接掌控，只能依賴 form 標簽的原生能力進行交互。如果使上例非受控組件變為一個受控組件，代碼也很簡單：

class NameForm extends React.Component {
  state= {value: ""}

  handleChange = event => {
    this.setState({value: event.target.value});
  }

  handleSubmit = event => {
    alert("A name was submitted: " + this.state.value);
    event.preventDefault();
  }

  render() {
    return (
      

        
          Name:
          
        
        
      
    )
  }
}

這時候表單值和行為都由 React 組件控制，使得開發更加便利。

這當然是很基礎的概念，借此拋出控制權的話題，請讀者繼續閱讀。

前文介紹的樣例，我稱之為“狹義受控和非受控”組件。廣義來說，我認為完全的非受控組件是指：不含有內部 states，只接受 props 的函數式組件或無狀態組件。它的渲染行為完全由外部傳入的 props 控制，沒有自身的“自治權”。這樣的組件在很好地實現了復用性，且具有良好的測試性。

但在 UI “輪子”設計當中，“半自治”或者“不完全受控”組件，有時也會是一個更好的選擇。我們將此稱之為 “control props” 模式。簡單來說就是：組件具有自身 state，當沒有相關 porps 傳入時，使用自身狀態 statea 完成渲染和交互邏輯；當該組件被調用時，如果有相關 props 傳入，那么將會交出控制權，由業務消費層面控制其行為。

在研究大量社區 UI “輪子” 之后，我發現由 Kent C. Dodds 編寫的，在 paypal 使用的組件庫 downshift 便廣泛采用了這樣的模式。

簡單用一個 Toogle 組件舉例，這個組件由業務方調用時：

class Example extends React.Component {
  state = {on: false, inputValue: "off"}
  handleToggle = on => {
    this.setState({on, inputValue: on ? "on" : "off"})
  }
  handleChange = ({target: {value}}) => {
    if (value === "on") {
      this.setState({on: true})
    } else if (value === "off") {
      this.setState({on: false})
    }
    this.setState({inputValue: value})
  }
  render() {
    const {on} = this.state
    return (
      

        
        
      
    )
  }
}

效果如圖：

我們可以通過輸入框來控制 Toggle 組件狀態切換（輸入 “on“ 激活狀態，輸入 ”off“ 狀態置灰），同時也可以通過鼠標來點擊切換，此時輸入框內容也會相應變化。

請思考：對于 UI 組件 Toggle 來說，它的狀態可以由業務調用方來控制其狀態，這就賦予了使用層面上的消費便利。在業務代碼中，不管是 Input 還是其他任何組件都可以控制其狀態，調用時我們具有完全的控制權掌控能力。

同時，如果在調用 Toggle 組件時，不去傳 props 值，該組件仍然可以正常發揮。如下：

  
    {({on, getTogglerProps}) => (
      

        Toggle me
        
{on ? "Toggled On" : "Toggled Off"}
      
    )}
  
  

Toggle 組件在狀態切換時，自己維護內部狀態，實現切換效果，同時通過 render prop 模式，對外輸出本組件的狀態信息。

我們看 Toggle 源碼（部分環節已刪減）：

const callAll = (...fns) => (...args) => fns.forEach(fn => fn && fn(...args))

class Toggle extends Component {
  static defaultProps = {
    defaultOn: false,
    onToggle: () => {},
  }
  state = {
    on: this.getOn({on: this.props.defaultOn}),
  }
  getOn(state = this.state) {
    return this.isOnControlled() ? this.props.on : state.on
  }
  isOnControlled() {
    return this.props.on !== undefined
  }
  getTogglerStateAndHelpers() {
    return {
      on: this.getOn(),
      setOn: this.setOn,
      setOff: this.setOff,
      toggle: this.toggle,
    }
  }
  setOnState = (state = !this.getOn()) => {
    if (this.isOnControlled()) {
      this.props.onToggle(state, this.getTogglerStateAndHelpers())
    } else {
      this.setState({on: state}, () => {
        this.props.onToggle(
          this.getOn(),
          this.getTogglerStateAndHelpers()
        )
      })
    }
  }
  setOn = this.setOnState.bind(this, true)
  setOff = this.setOnState.bind(this, false)
  toggle = this.setOnState.bind(this, undefined)
  render() {
    const renderProp = unwrapArray(this.props.children)
    return renderProp(this.getTogglerStateAndHelpers())
  }
}

function unwrapArray(arg) {
  return Array.isArray(arg) ? arg[0] : arg
}
export default Toggle

關鍵的地方在于組件內 isOnControlled 方法判斷是否有命名為 on 的屬性傳入：如果有，則使用 this.props.on 作為本組件狀態，反之用自身 this.state.on 來管理狀態。同時在 render 方法中，使用了 render prop 模式，關于這個模式本文不再探討，感興趣的讀者可以在社區中找到很多資料，同時也可以在我新書中找到相關內容。

盤點一下，control props 模式反應了典型的控制權問題。這樣的“半自治”能夠完美適應業務需求，在組件設計上也更加靈活有效。

提到控制權話題，怎能少得了 Redux 這樣的狀態管理工具。Redux 的設計在方方面面都體現出來良好的控制權處理，這里我們把注意力集中在異步狀態上，更多的內容還請讀者關注我的新書。

Redux 處理異步，最為人熟知的就是 Redux-thunk 這樣的中間件，它由 Dan 親自編寫，并在 Redux 官方文檔上被安利。它與其他所有中間件一樣，將 action 到 reducer 中間的過程進行掌控，使得業務使用時可以直接 dispatch 一個函數類型的 action，實現代碼也很簡單：

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => next => action => {
    if (typeof action === "function") {
      return action(dispatch, getState, extraArgument);
    }

    return next(action);
  };
}

const thunk = createThunkMiddleware();

export default thunk;

但是很快就有人認為，這樣的方案因為在中間件實現中的控制不足，導致了業務代碼不夠精簡。我們還是需要遵循傳統的 Redux 步驟：八股文似的編寫 action，action creactor，reducer......于是，控制粒度更大的中間件方案應運而生。

Redux-promise 中間件控制了 action type，它限制業務方在 dispatch 異步 action 時，action的 payload 屬性需要是一個 Promise 對象時，執行 resolve，該中間件觸發一個類型相同的 action，并將 payload 設置為 promise 的 value，并設 action.status 屬性為 "success"。

export default function promiseMiddleware({ dispatch }) {
  return next => action => {
    if (!isFSA(action)) {
      return isPromise(action) ? action.then(dispatch) : next(action);
    }

    return isPromise(action.payload)
      ? action.payload
          .then(result => dispatch({ ...action, payload: result }))
          .catch(error => {
            dispatch({ ...action, payload: error, error: true });
            return Promise.reject(error);
          })
      : next(action);
  };
}

這樣的設計與 Redux-thunk 完全不同，它將 thunk 過程控制在中間件自身中，這樣一來，第三方輪子做的事情更多，因此在業務調用時更加簡練方便。我們只需要正常編寫 action 即可：

dispatch({
    type: GET_USER,
    payload: http.getUser(userId) // payload 為 promise 對象
})

我們對比一下 Redux-thunk，相對于“輪子”控制權較弱，業務方控制權更多的 Redux-thunk，實現上述三行代碼，就得不得不需要：

dispatch(
    function(dispatch, getState) {
        dispatch({
            type: GET_USERE, 
            payload: userId
        })
        http.getUser(id)
            .then(response => {
                dispatch({
                    type: GET_USER_SUCCESS,
                    payload: response
                })
            })
            .catch(error => {
                dispatch({
                    type: GET_DATA_FAILED,
                    payload: error
                })
            }) 
    }
)

當然，Redux-promise 控制權越多，一方面帶來了簡練，但是另一方面，業務控制權越弱，也喪失了一定的自主性。比如如果想實現樂觀更新（Optimistic updates），那就很難做了。具體詳見 Issue #7

為了平衡這個矛盾，在 Redux-thunk 和 Redux-promise 這兩個極端控制權理念的中間件之間，于是便存在了中間狀態的中間件：Redux-promise-middleware，它與 Redux-thunk 類似，掌控粒度也類似，但是在 action 處理上更加溫和和漸進，它會在適當的時機 dispatch XXX_PENDING、XXX_FULFILLED 、XXX_REJECTED 三種類型的 action，也就是說這個中間件在掌控更多邏輯的基礎上，增加了和外界第三方的通信程度，不再是直接高冷地觸發 XXX_FULFILLED 、XXX_REJECTED，請讀者仔細體會其中不同。

了解了異步狀態中的控制權問題，我們再從 Redux 全局角度進行分析。在內部分享時，我將基于 Redux 封裝的狀態管理類庫共同特性總結為這一頁 slide:

以上四點都是相關類庫基于 Redux 所進行的簡化，其中非常有意思的就是后面三點，它們無一例外地與控制權相關。以 Rematch 為代表，它不再是處理 action 到 reducer 的中間件，而是完全控制了 action creator，reducer 以及聯通過程。

具體來看：

業務方不再需要顯示申明 action type，它由類庫直接函數名直接生成，如果 reducer 命名為 increment，那么 action.type 就是 increment；

同時控制 reducer 和 action creator 合二為一，態管理從未變得如此簡單、高效。

我把這樣的實踐稱為控制主義或者極簡主義，相比 Redux-actions 這樣的狀態管理類庫，這樣的做法更加徹底、完善。具體思想可參考 Shawn McKay 的文章，介紹的比較充分，這里我不再贅述。

控制權說到底是一種設計思想，是第三方類庫和業務消費的交鋒和碰撞。它與語言和框架無關，本文只是以 React 舉例，實際上在編程領域控制權的爭奪隨處可見；他與抽象類別無關，本文已經在 UI 抽象和狀態抽象中分別例舉分析；控制權與碼農息息相關，它直接決定了我們的編程體驗和開發效率。

可是在編程的初期階段，優秀的控制權設計難以一蹴而就。只有投身到一線開發當中，真正了解自身業務需求，進而總結大量最佳實踐，同時參考社區精華，分析優秀開源作品，相信我們都會得到成長。

最后，前端學習永無止境，希望和每一位技術愛好者共同進步，大家可以在知乎找到我！

Happy coding!

Happy coding!

《React 狀態管理與同構實戰》這本書由我和前端知名技術大佬顏海鏡合力打磨，凝結了我們在學習、實踐 React 框架過程中的積累和心得。除了 React 框架使用介紹以外，著重剖析了狀態管理以及服務端渲染同構應用方面的內容。同時吸取了社區大量優秀思想，進行歸納比對。

本書受到百度公司副總裁沈抖、百度資深前端工程師董睿，以及知名 JavaScript 語言專家阮一峰、Node.js 布道者狼叔、Flarum 中文社區創始人 justjavac、新浪移動前端技術專家小爝、百度資深前端工程師顧軼靈等前端圈眾多專家大咖的聯合力薦。

有興趣的讀者可以點擊這里，了解詳情。也可以掃描下面的二維碼購買。再次感謝各位的支持與鼓勵！懇請各位批評指正！