摘要：但還存在一些問題，比如，單向數(shù)據(jù)流導致的有時數(shù)據(jù)鏈過長過繁瑣所以才產(chǎn)生了，需要在多地保存同一份數(shù)據(jù)等等。數(shù)據(jù)流細粒度的目前來說，我們的的甚至是還是設計得太過簡單。

??由于筆者對React的了解不深，即便算是學習React的時間，到目前也才剛剛半年，所以錯誤不足之處還望指正。以下都是基于React 15（可能有些是16），webpack1進行探討（注：未學習過Vue，Ng，Ember，Cycle，Immutable，Redux-Saga，Mobx，Observable，Rxjs等等，所以可能有些方面已經(jīng)被提及或者解決了，希望不要介意）。

本文的排版可能不那么正經(jīng)，想到哪寫到哪，見諒見諒。

JSX

備受關(guān)注（吐槽）的if問題： 要討論這個問題，首先要明白jsx是轉(zhuǎn)換的是什么，只有這樣，你才明白為什么不能在jsx里面寫if語句，switch語句，為什么只能寫表達式等等。好了，回到正題，我們困撓，那么其他的程序猿肯定也是這樣滴，那么正確的姿勢是什么呢？沒錯，提isssue&討論，我們先來看看已有的提出的一些方案（來自JSX的issue，其他的諸如三目，把邏輯提取出來寫在外面，多return方式，IIFE，do expression等等這里就不多說了）：

NO.1

https://github.com/facebook/jsx/issues/65#issuecomment-254056396


  
This part only gets shown if myCondition is true

NO.2

https://github.com/facebook/jsx/issues/65#issuecomment-255465492（官方人員提出的，所以采用的概率稍微要高一點，基于do expression）


  Hi!
  {if (bool)  else 
}



NO.3
https://github.com/facebook/jsx/issues/65#issuecomment-255484351

 }
  else={  }
/>

function If(props) {
  const condition = props.condition || false;
  const positive = props["then"] || null;
  const negative = props["else"] || null;
  return condition ? positive : negative;
}

當然，新的語法就意味著新的符號（一般來說），所以這種變化不一定是好的，也不一定每個人都能接受。
比如bjrmatos說的

"It"s just JavaScript, not a template language" -> no need to replicate JS functionalities with custom syntax. That is the main benefit of JSX IMO, seriously is so easy to do this with js even if it looks "weird" (for me it is not weird, it is just the syntax of the language)

比如jmar777說的：
  [if (condition)]
    
    
    
  [/if]
We instead need:
{ condition &&  }
{ condition &&  }
{ condition &&  }
If the condition itself gets more complex, then the code gets uglier, or alternatively we need to store the result to a temporary variable, which further increases the verbosity. I will note that this particular pain point would be eased by better support for fragments.

TBH I"ve never seen a specific proposal that I"m overly fond of, but inasmuch as branching logic is integral to all but the most trivial of rendered outputs, I think there"s a compelling case to be made for first-class support in JSX.
Atrribute autocomplete（這也是我們的愿望之一，畢竟可以減少很多無用功，代碼也更整潔）

render () {
  const {
    prop1,
    prop2,
    prop3
  } = this.props

  return (
    
  )
}
Or
render () {
  const {
    prop1,
    prop2,
    prop3
  } = this.props

  return (
    
  )
}
Instead Of
render () {
  const {
    prop1,
    prop2,
    prop3
  } = this.props

  return (
    
  )
}

希望支持數(shù)字attribute省略花括號

還有的人希望對于字符串類型的attribute，能夠省略引號。seb最后也解釋了為什么沒有允許可以對字符串屬性進行簡寫（因為存在兩種不同的語義，如果允許去掉，到底以哪個為準呢）


https://github.com/facebook/jsx/issues/25#issuecomment-137224657

I think the conclusion is that since these forms are currently semantically different in JSX parsers:

 // Foo & Bar
 // Foo & Bar

We should keep it consistent which would mean that this would also be different:

 // Foo & Bar
 // Foo & Bar
Attribute Destructuring
https://github.com/facebook/jsx/issues/76



// 當然也可以先解構(gòu)了再賦過去，不過那樣肯定是要麻煩一點。最后seb也說了，如果https://github.com/RReverser/es-borrowed-props這個提案有進展的話就更好了

Attribute Or Children

寫過組件的同學應該有時候會遇到這樣的情況，我們需要調(diào)用方傳過來一個組件，那么問題來了，這個組件到底是以children的形式還是props的形式傳過來呢？有時候我們只需要一個組件，那么都可以（當然還有考慮語義和大家的慣性思維）。如果需要多個組件就不行了，就需要進行抉擇，有時候明明覺得都該以children的形式傳進來，但是無奈必須做出取舍。所以我們可以看到比如有些同學就提出了：
NO.1 attribute2Children模式


https://github.com/facebook/jsx/issues/65#issuecomment-254060186

...
}
   right={
...
}
/>
// vs

   <.left>
     
...
   
   <.right>
     
...
   

NO.2 style（其實也是attribute2Children模式）

https://github.com/facebook/jsx/issues/65#issuecomment-254100455


// or

關(guān)于bind的問題，目前都基本用class里用箭頭函數(shù)的方式了。但是依然存在一個問題，在某些情況下我們依然需要使用bind（當然用閉包也可以，不過面臨的問題是一樣的）。比如，我們想給我們的處理函數(shù)傳遞參數(shù)，我們就不得不使用諸如的方式，但是眾所周知，這樣會造成Foo組件的props每次都會變化，對于PureCompoennt可能有性能影響，（雖然如果這里不是bar而是ref的話不會存在這樣的問題，因為淺比較的時候根本不會考慮key和ref），當然我們可以自己定義shouldComponentUpdate然后自己手動比較下，如果nextProps的arg和現(xiàn)在的arg一樣的話（當然這里會根據(jù)arg是否是對象比較的策略會不一樣），那么我們就采用之前的函數(shù)（假設我們緩存了）。

這樣一看似乎還行，但是仍然存在一個問題（其實我們完全沒有必要考慮這些，因為對性能真的沒啥影響，性能基本不會通過這些得到改善或者降低，但是本著深挖洞，廣積糧的精神，思考思考還是可以的）。什么問題呢，就是如果這個arg是一個函數(shù)或者說是包含函數(shù)的對象，那么兩個函數(shù)相等就能夠推導出他們真的相等嗎？或者說兩個函數(shù)不相等就能推導出他們真的不相等嗎？顯然不能這樣，因為函數(shù)可能“不純”。這就給我們的判斷工作帶來了一定的影響，之前沒有出錯過是因為出錯的幾率本身就很低，因為props和state本身都是“純的”，沒有人會去手動修改它（即直接賦值）。我們不那么認真的來看一下下面的例子：

 class Bar extends Component {
shouldComponentUpdate (nextProps, nextState) {
  if (this.props !== nextProps) {
    // 問題就出在這里，假設此后我們需要調(diào)用p2

    if (nextProps.p2 !== this.props.p2) {
      // 那么這里到底該返回true還是false呢
      // 返回true，那如果p2()的值沒變怎么辦，算不算是一種浪費
      // 返回false，那如果p2()的值變了怎么辦
    } else {
      // 這里p2相等了，我們能在之后調(diào)用之前緩存的p2嗎（假設緩存過了，當然緩存的前提一般都是pure的才能緩存哈）？也不能，因為p2可能從一個“純”的變成“不純”的了。另外返回false還是true和上面的同理。
      }
     
   // 所以最后我們會發(fā)現(xiàn)，我們根本沒法判斷，因為我們不知道p2到底“純”還是“不純”
  }
}
     
   render () { console.log(...this.props); return null; }
 }
  
let externalData1 = "extenalData1";
setTimeout(() => externalData1 = "externalData2", 1000);
let util = (...args) => utilFunc(...args, externalData1);
  
class Foo extends Component {
state = { arg1: "1", arg2: util("aa") }
  
componentDidMount () {
  this.setState({ arg1: "2", arg2: util("bb") });
}
 
handleSomething (...args) {
  console.log(...args);
    
  ...somethingElse
}
  
render () {
  const { arg1, arg2 } = this.state;
 
  return (
    
  );
}
}

組件

一般來說，我們將組件分為兩大類，即基礎組件與業(yè)務組件。在React中，基礎組件基本已由Ant Design（PC端）覆蓋完畢，將來可能會有一些變動/更新，但是都不會太大。基于基礎組件的封裝/改寫，依舊屬于基礎組件。業(yè)務組件基于基礎組件，此時就面臨一個非常重要的問題，數(shù)據(jù)/數(shù)據(jù)流相關(guān)的處理（這個后面再談）。除此之外，主要想提及一下，還應該有一類組件，暫且稱之為邏輯組件，為什么要分出來呢，因為確實感覺這兩類都不太能準確的描述它。比如，、、（或者之類的）我們的系統(tǒng)基本就是由這三種組件進行拼裝。

表單。

我們從最簡單的說起。一個input，不包含任何聯(lián)動。那么現(xiàn)在存在一個問題，就是每一個input我們都要建立與之對應的onChange函數(shù)（假設我們每一個input都采用Controlled Components的形式，因為可控性要好一點。同時都有自己的邏輯，不單單是setState(e.target.value)），太麻煩了。理想的情況是怎么樣的呢，我們應該可以采取動態(tài)建立的方式，只需要提供字段名，自動將值注入到state中，以及自動在組件的this或者原型鏈上創(chuàng)建對應的onChange函數(shù)，然后再賦給input（當然這樣的話基本上要完全依賴提供的組件庫，不能期望自己隨便寫一個input也能自動達到這樣的效果）。

那么問題來了，這里需要加糖（使代碼更少）和defineProperty（或者Proxy）（使修改更直接方便）嗎，個人認為，都不可。因為這都會增加debug的難度。我還是更傾向于前面提到的簡單封裝，然后還是用setState去改變字段。現(xiàn)在流行的主要有antd的form以及redux-form。但是個人認為這并不是最好的方式，因為感覺有點亂，舉個比喻的話，感覺有點像寫傳統(tǒng)的模板一樣，當然，也許就是要專門治治我們這些處女座。

下面說說聯(lián)動的情況。在以前（如jQuery），我們要處理聯(lián)動，必須手動維護聯(lián)動的關(guān)系，所以要么在onChange里面根據(jù)邏輯手動觸發(fā)其他組件的更新，要么是采用after或者callback queue的方式，總之，重心是維護邏輯而不是數(shù)據(jù)。那么是否應該存在一種方式，讓我們的重心靠到數(shù)據(jù)上面？這樣debug，開發(fā)，維護都輕松一些。對于React應用而言，天然的解決了部分問題。但還存在一些問題，比如，單向數(shù)據(jù)流導致的有時數(shù)據(jù)鏈過長過繁瑣（所以才產(chǎn)生了redux），需要在多地保存同一份數(shù)據(jù)等等。

以上僅僅是一些思考，關(guān)于表單的探索還沒有開始（因為目前表單相關(guān)的需求還不是很多和復雜，過段時間研究研究之后希望能解決一些問題）。

Encapsulated Compose Or Custom Compose

舉例來說。例如響應式，我了解到這個概念應該是從bootstrap的柵格開始，到后面antd也有對應的Grid系統(tǒng)，包含了Row和Col。那么問題來了，當實現(xiàn)一個響應式列表或者table的時候，是否應該自己去組合，即哪些地方寫個Row，然后下面的Col的sm，md等等依次是多少，挨著填進去。還是說我們先把這些組合邏輯封裝好，比如：

const responsive = responsivelizeComponent({
  xs: 1,
  sm: 2,
  md: 2,
  lg: 2,
  pc: 3
});

然后調(diào)用，傳入數(shù)據(jù)，以及Row，Col對應的組件：

{ 
  responsive(
    list, 
    () => , // 這里如果C本身就是Row，那么就進行props合并，如果不是Row，那么需要在處理的時候包裹在Row里面
    () => 
  )  // Item同理，只是換成了Col
}

Component Middleware： 我們知道，中間件的概念由來已久了（歷史就沒有去考證了，node也不熟悉就不談了哈哈）。在redux中，我們就可以創(chuàng)建一系列的中間件去處理我們的action。那么，組件是否也可以具備這樣的能力呢（即組件中間件）？答案是肯定的，decorator就是一個很好的例子，但是decarator與middleware還是存在一定的差距，一是書寫上不直觀/美觀（目前個人能忍受的就是最多1個@），二是控制的力度太小。三是沒有形成一個整體，各個部分只能跟自己的上游打交道。這些方面才剛剛開始探索，就不在大佬們面前介（zhuang）紹(bi)了。

Redux

細粒度的actionType：

目前來說，我們的action的type甚至是action還是設計得太過簡單。我們完全可以進一步進行設計來減少我們的工作量。比如，我們可以看到redux初始化store時的actionType為@@INIT，受此啟發(fā)，我們完全可以自定義更復雜的actionType甚至action，配置中間件進行處理。比如@@FOO@@BAR/xx_TODO，或者像官方例子中的那樣const CALL_API = symbol("CALL_API"); action = { [CALL_API]: {...} }，然后建立與之對應的middleware，從而減少reducer的數(shù)量。當然這是一個開頭，復雜應用應該是存在很多個middleware進行職能分工（沒有復雜應用的經(jīng)驗，這里就不多說了）。

actionType可以與相應的處理的函數(shù)的名字形成包含關(guān)系，減少switch里的case代碼量。比如，在reducers/foo.js中，聲明了一系列的handlexxxxType，那么我們可以在foo.js中import * as all from "./foo.js";，然后創(chuàng)建一個類似于mapActionTypeToHanleFunction的處理函數(shù)。這里就不用在每個case都去調(diào)用某個函數(shù)了。

一次用戶操作導致的多個位置的數(shù)據(jù)變動是否都可以通過接連觸發(fā)不同的dispatch action來實現(xiàn)？答案是否定的，比如dispatch某個action，目的是刪除某個實體，但是同時sotre中其他某個地方存儲了這個id，或者說一個ids數(shù)組里包含了這個id，那么在這次dispatch完成之后的更新里就會出錯，所以我們不能再dispatch一個action去同步的刪除這些數(shù)據(jù)。我們只能在不同的reducer里面監(jiān)測第一個dispatch的action，然后處理。

還有一個就是群里工業(yè)聚大大提到的，action實際上和HTTP請求非常相似，能否用處理HTTP請求的方式去規(guī)劃redux？

Redux-Orm：顧名思義，這就是一個ORM庫（畢竟這是一個前端的數(shù)據(jù)庫嘛，之前想過redux配合indexDB，后面發(fā)現(xiàn)也不是很方便）。使用后的感受是，確實比純的redux方便一些（廢話，不然人家創(chuàng)建這個干嘛）。具體的比較等之后用了mobx，immutable和rxjs之后再放在一起比較吧。

React要想觸發(fā)更新只能采用setState（拋開forceUpdate不談），所以這就限制了我們修改數(shù)據(jù) -> 自動觸發(fā)所有相關(guān)更新這種操作，其他的應用我們可以記錄所以依賴于這個數(shù)據(jù)的組件，然后修改數(shù)據(jù)的時候依次觸發(fā)它們。但React的話要想實現(xiàn)這個就必須繞一個圈子，如redux方案。同時還存在一些弊端，比如：

一是依賴某個數(shù)據(jù)的明明只有A，B組件，為什么我還要挨個通知C，D組件，C，D組件明明是依賴于另外的數(shù)據(jù)的。即便react-redux內(nèi)部進行了很多性能優(yōu)化來避免不必要的更新（實質(zhì)也就是盡量確保兩點，一是我不需要的數(shù)據(jù)不應該觸發(fā)我的更新，二是即便是我需要的數(shù)據(jù)，沒變化的情況下也不應該更新）。因為redux和react-redux是隔離的，redux就是一個數(shù)據(jù)（包裹/快遞）倉庫，當有包裹來的時候，他可以在自己內(nèi)部對包裹進行分類，把包裹放在指定的某個或某些區(qū)域（當然數(shù)據(jù)天然是可copy很多份的，包裹只有一份，就不要糾結(jié)這個啦），然后呢，包裹要出庫該走倉庫的哪個門呢？不清楚。。type只是倉庫內(nèi)部分類時用于參考的一個東西，對外部并沒有作用。

所以它只能依次打開倉庫的所有門，拿上擴音器大喊，倉庫包裹更新啦，快來看看你們那兒要不要搞些事情～，這里其實就存在一個問題，倉庫里哪塊區(qū)域的包裹更新了其實倉庫本身是可以知道的，但是目前他沒有做記錄，這就導致了收到通知之后的前來的公司又必須親自去倉庫里找自己需要的包裹(selector)，與此同時，倉庫也不能保證這批包裹屬于這一次包裹更新中的包裹(即selector出來的并沒有發(fā)生變化)。所以這就造成了資源的浪費，有可能一次dispatch最后倉庫里沒有任何包裹更新，倉庫也必須挨個打開出庫門。二就是前面提到的有更新也不應該挨個打開出庫門。

因此，可能地更好的一種方式是。組件應該把自身可能需要的包裹提前告訴倉庫，細粒度一點的，當然既可以是就在type和包裹間建立一種映射關(guān)系，如{type: { name: "update_todo", from: this, need: ["foo", "bar"] }}（foo和bar是store中的某個key）， 粗粒度的話（有些case可能不能這樣做），就不自己去添need參數(shù)了（但是還是要寫from），可以直接讓redux本身進行統(tǒng)計，因為一個action導致了哪些reducer發(fā)生了變化這個它是能夠統(tǒng)計的（也不難，很早的版本中在combineReducer中就有hasChanged的flag了），最后也能形成一個type到need的映射。然后組件也把need參數(shù)傳給connect，同時，redux內(nèi)部的listeners就不應再是一個簡單的回調(diào)數(shù)組了，需要按need進行歸類，這樣我們才能保證不是去通知每個subscribe了的組件，而是確實需要這次更新的我們才通知。還有就是，既然有了need，也不再需要selector了，我們在通知的時候就自動在store中把對應的need傳過去了。（這里需要注意到是，對于實體數(shù)據(jù)，store存儲的數(shù)據(jù)肯定還是要normalize后的，不然數(shù)據(jù)冗余很嚴重，但是我們通知的時候沒有必要再denomalize解范式化或者說像傳統(tǒng)的挨個把外鍵轉(zhuǎn)換為實體，我們直接建立一個reducer存儲當前的dispatch對應的網(wǎng)絡請求的response）

另外這些方面徐飛叔叔的文章真的是寫得非常非常不錯，自己的想法很多時候就是小巫見大巫了，之后一定還是要抽空多琢磨幾遍。

全局與局部： 從整個項目來講，可以將第三方非CSS Modules模塊的css統(tǒng)一放在一個目錄下，不做CSS Modules處理。局部的話用global語法就行了。

模塊復用： 比如有兩個css模塊，a.css和b.css，我們知道，composes是給對應的標簽的class加上某個css類，而不是像傳統(tǒng)的使兩個類都具備同樣的規(guī)則。對于在業(yè)務組件中composed基礎組件這樣還好，但是如果是composes其他的業(yè)務組件，就會顯得有點怪怪的，比如

命名： 模塊化能一定程度上減少長命名，但是無法完全消除長命名。因為缺少需要它。比如一個組件內(nèi)的一個list，依然需要寫成list，list-item，相比以前，省去了xx-list中的xx。但有些情況下，比如item下面的內(nèi)容很少，就一兩個，我們不想多帶帶提取出來，那么就得寫成list-item-xxx，確實看著有一點不美觀。

Css的模塊是否應和js模塊耦合？ 通常來說，我們一個css模塊會對應一個js模塊（除去皮膚，改版這些）。但是除此之外，是否應該存在多帶帶的CSS模塊，它們不屬于具體的某個基礎組件或者業(yè)務組件，而是共享給這些組件去使用或者說組合。目前這方面沒有實踐過，就不多說了。

Css Modules與React結(jié)合

目前已有的方案有react-css-modules以及babel-plugin-react-css-modules，它們的作者是同一個人，后者是前者的改進版本，這位作者也是medium上那篇大家熟悉的stoping css in js的作者。

前者（react-css-modules）存在的問題有，一是性能，因為采用的是HOC的模式，導致在生產(chǎn)環(huán)境每次渲染也要走一遍檢索css映射表的過程，造成性能損耗。二是書寫方式麻煩，即便用了decorator，也還是要老是重復同樣的代碼。三是某些情況下要在一個組件內(nèi)使用多次HOC，整潔性和方便性都不太好。這些在README中基本都有提到。還有就是不能寫空的css規(guī)則，內(nèi)部對此會拋出異常（之前被這個坑過，剛好那個時候的chrome版本吞錯，找了很久才發(fā)現(xiàn)是這里的問題）。后面跟作者交流了一下，提出了空的css規(guī)則的適用場景和初衷，所以在babel-plugin-css-modules中對于此采用警告而不再是拋出異常。

后者（babel-plugin-react-css-modules）基本上解決了上述提到的所有問題。但是還有一個地方值得思考一下，那就是import機制的問題，個人認為還需要增加一種特性（可配置對于每個js模塊是否啟用），即import多個css也不需要指定importName，默認后面的會覆蓋前面引入的css中的同名class，否則我們還是要寫成foo.a bar.b的形式，喪失了我們使用這個的部分初衷。

另外采用這樣方式暫時有個缺點就是IDE支持不好（沒有自動補全提示），盡管7月份發(fā)布的最新版webstorm對原生的CSS Modules支持度更好了（style.這種方式后會有自動補全的提示）。

npm是否應該具備更強的約束？即語義版本號必須滿足語義所賦予的條件，從而讓打包的時候不會1.0.1和1.0.2都打包，應該只打包1.0.2，那個依賴1.0.1的包轉(zhuǎn)而去依賴1.0.2，從而使得只打包一個。更有想法的是，上傳到npm上的包必須提供類似react-codemod的機制（這個確實很難，不知深度學習能否有幫助），從而可以讓所有使用這個包的應用無痛自動升級，從而實現(xiàn)哪怕是有breaking change的版本更新，比如1.0.2變成1.1.0，最后也只會打包1.1.0。之前包括現(xiàn)在，這部分內(nèi)容都是通過changelog或者官網(wǎng)更新的方式發(fā)放出來。然后讓開發(fā)者自己去解決。

一個目錄下有多個js文件，此時一般會建立一個index目錄去導出這個目錄下所有js里的default以及普通export的變量（當然前提是沒有重復的），目的是為了import的時候直接import index文件，避免去記憶某個變量在哪個js文件中。但是這樣有一個麻煩，那就是每次新增js文件的時候都需要記得去index進行export。那么我們?yōu)槭裁匆限@北轍的去搞一個index文件呢，我們的目的不就是要import方便嗎，為什么不讓編譯器（其實webpack的alias也可以，但是畢竟是第三方，包括fb內(nèi)部也有自己的模塊導入系統(tǒng)，但是弊端他們也說了）去自動尋找包含我們要引入的那個變量都有哪些js文件然后給我們一個清單呢，就像JAVA的import機制那樣，按ctrl+shift+o自動import，如有重復的會讓你選擇到底以哪個文件導出的為準（當然也有些特殊情況，比如我們需要用as取別名）。

越復雜的項目，粒度越小，耦合度越低的項目，組件的數(shù)量會成倍的增加，如fb就有3W個組件。那么，我們?nèi)绾闻袛嗄硞€組件我們或者別人或者團隊之前是不是寫過，如果是，我們又如何知道這個組件的名字是什么，在哪個位置？（fb雖然有fbjs是開源的，但是那個有點像util，而不是component庫，所以也不知道內(nèi)部到底怎么搞的，之前也只是問過對于react源碼他們是不是有比較方便的管理工具，能夠快速定位某個功能或者名字或者注釋在哪個地方，得到的答案是，沒有）。

錯誤處理（16beta昨天剛發(fā)布了，官方有文檔了，就看官方的啦），構(gòu)建，測試，體積優(yōu)化，部署以后再談了（其實是因為沒什么經(jīng)驗）。嗯，這次就先這樣吧