【前端】react學習階段總結，學習react、react-router與redux的這些事兒

前言

　插一下，我發現好多踩。。。。。是理解失誤么？  歡迎指正。

---------------------------------------------

　　借用阮一峰的一句話：真正學會 React 是一個漫長的過程。 這句話在我接觸react深入以后，更有感觸了。整個react體系都是全新的，最初做簡單的應用，僅僅使用react-tools打包jsx時，我被react的函數式語法吸引，從而跳入這個圈子。一直到搭建webpack、react、react-router、redux架構，做了幾個SPA項目，我還是感覺自己懂的太少，還在第一階段徘徊，在這里暫時做一個階段性總結，接下來將繼續更深入了解react——不排除再轉回vue。嘿嘿。

函數式組件

react是一個由多個組件組成的web工程或者app，而這些組件都是通過一個函數對象組成的，例如

React.createClass({
   render:function(){
     return <div>hello</div> 
   } 
})

這是一個es5的寫法，也是我最初接觸時使用的手法。通過聲明reactClass注冊組件，通過render定義組件的jsx。

目前我的理解是：無論是es5的createClass亦或是es6的class，其組件核心在於，創建一個構造函數，這個構造函數中的成員定義了組件的視圖、行為、狀態、生命周期、再通過jsx和react-dom結合渲染，實現函數式組件。

更通俗的理解我覺得是，每一個組件其實都是一個類，這個類繼承了react的核心，通過重寫定義組件。這里使用web說明：

這就是我認識到的react的基本組成。

 

難點，狀態管理

　　react的難點之一是狀態管理，好在還有Flux，redux，這些解決方案，得益於大公司（facebook）的明星效應，react的社區活躍度很高（但是我很少看到比較高質量的中文react解決方案），這類的難點解決方案總會有很多選擇。鑒於redux的流行程度，國內大多數應該都是它了吧，甚至據我所知，react在國內的使用程度比不上vue、angular。

　　還是談談我對狀態管理的理解；這里不提redux等解決方案，我們往往需要先搞清楚為什么要用解決方案，再去用解決方案。

前面提到了函數式組件，一般我們做項目的時候，一個組件不會僅僅滿足於返回一個靜態dom，我們需要能夠管理組件的刷新、更改、ajax查詢等。

react中引入了一個叫做getInitialState的方法，它就是用來定義組件的狀態，這個方法在不同的js版本中有不同的實現：

es5:

React.createClass({
    getInitialState:function(){
      return {
          text:"hello world"
       }     
    },
    render(){
        return <div>{this.state.text}</div> 
    }
})

es6:

import React,{Component} from "react";
class Hello extends Component{
   constructor(props){
    super(props);
    this.state={
        text:"hello World"
    }
  }
   render(){
        return <div>{this.state.text}</div>  
    }
}    

如果你看babel打包后的代碼，通過打包后的代碼也可以看出es6轉換成 getInitialState聲明形式。

該如何理解組件狀態呢？ 

這樣看其實更簡單，簡單來說組件hello有一些組件屬性，例如props、state。 state是實時管理組件，用什么樣的樣子顯示到webview中的決定屬性。 

對這樣一個組件來說，這樣其實很簡單了。但是想想一個頁面可以拆分成多少個組件，這么多組件在一起組合、嵌套，你想想每個組件都有一個自己的state，如果外面的組件要控制里面的組件呢？a組件要控制b組件呢？，復雜程度立刻變為困難模式。但是刀山火海總會填平的，這就是redux解決的問題。

然而伴隨redux而來的，是一堆貼着標簽的，嘴角還露着尖尖的邪笑的喪屍大軍，哦，那是更多的技術棧體系。。。。。。

難點，項目控制

　　用react做的項目會不會腐爛掉？我的經驗是，會的，而且爛的也很難看。且看可能出現的情況

　　1.某個猿A，開發了一個頁面，其中有10個組件。用到3個全局狀態。組件嵌套良好，代碼規范。就像下圖的頁面關系。

        

　　2.某個猿B（新手），接手了猿A的頁面后，用到1個全局狀態。增加一個組件，由於他可能不清楚猿A的那10個組件中的關系。

       有可能變成了這樣：

     

這可能是比較樂觀的情況，更糟糕的可能是，他創建了一個依賴大部分組件的組件。。。而這些組件又依賴某些state......

這是我目前項目中感觸到的。

 

SPA的問題

　　 毫無疑問，spa適合那些簡單的web架構。

        更復雜一點兒的頁面使用就顯得很糟糕。它並沒有帶來更多的體驗。我看過最誇張的，是es項目里面一個叫做kibana的監控平台，它的主文件大小是3970k！ 整個頁面幾乎有6-8m！即使配合緩存技術，第一次加載都會慢的無法忍受。伴隨之的，是項目復雜程度直線上升，因為router多了，router復雜了，切換協調可沒有以前的html那么容易。

　　我有一個解決方案，那就是多SPA模式，我使用緩存協調多頁面state，每個頁面是一個SPA，例如列表頁、內容頁、評論頁，組成一個SPA，反而更簡單。

我的state處理方式：

var state = localStorage.getItem("state");
if(state === null || state === 'null'){
    state = {
        //頁面標題
        title:"資源服務總線"

    }
    localStorage.setItem("state",JSON.stringify(state));
}
else{
    state = JSON.parse(state);
}
export {state}

 多頁面使用 localStorage 共享state。每個站點應用都是一個SPA。

 

總結

　　篇幅有限，階段性的總結總是會有很多內容的，撿一些重要的，需要深刻再理解的說明。

每篇博客都代表自己的一次成長，因為我記得有一個人說：看的學習效率是10%，做的學習效率是50%，而總結的效率是70%，教授給別人是最多的100%。

另外，有不對之處，歡迎指正，感謝。

 

=============================

轉載需在明顯處注明作者與出處鏈接。謝謝