單頁應用開發總結

zzbo 發布于2019-08-20 17:01 / 1387人閱讀

摘要：本文想通過自己這一年的單頁應用開發經驗，來對的開發做一個總結。但是要知道，現如今頁面都比較復雜，一般的單頁應用都需要一個可靠的數據流去處理，否則在日后維護方面會難度巨大。

本文想通過自己這一年的單頁應用開發經驗，來對SPA的開發做一個總結。

頁面開發模式

通常我們在開發頁面時，都會拿到一份設計圖，假設我們拿到一份這樣的設計圖

對于頁面的開發，我總是遵循自上而下的設計模式去開發。在這里首先會把頁面分為兩部分，頭部導航，和內容主體。內容主體又分為兩部分左側關注信息以及右側的動態列表。如果按照這樣分，我們的組件編寫會像如下這樣

這樣寫其實沒什么問題，把所有的細節全部隱藏在組件內部，每個組件只要處理好自己就OK。但是要知道，現如今頁面都比較復雜，一般的單頁應用都需要一個可靠的數據流去處理，否則在日后維護方面會難度巨大。這里假設我們使用了redux，在redux中，我們的數據都是從頂層往下傳，一般以route頁面為維度，去做connect，然后route頁面將所需的store以及action以props的形式分發。那就相當于，整個頁面只有route組件是智能組件，其他組件盡可能寫成木偶組件。如果按照這樣的開發模式去開發左側關注列表組件，應該是這樣的

//BodyLeft

而list組件應該可能是這樣的

//List

  {data.map(item=>(
    {item.name}
  ))}

這時如果route頁面想傳遞什么信息給左側列表，每次都要層層傳遞，少了一層，多了可能會有兩三層，這樣會寫很多沒用的信息，并且很不利于日后的維護，因為每次有更改，都要去改許多無用的地方（那些中間層）。
而我個人更傾向一種扁平化的組件設計風格。
還是原來的頁面，如果采用扁平化的設計模式，設計出來的組件結構是這樣的

//ps：組件命名隨便取的

首先最外層的布局是可以復用的。這也就意味著如果之后還有頁面是這樣，上下布局，下面又是左右布局的時候，可以拿來用。其次是數據的傳遞不需要像之前那樣層層傳遞，可以直接傳給想要的組件。

有人說route頁面為什么不能這樣寫

...

也就是說把之前的那些組件換成div不就好了。但是在組件設計哲學里，通常在connect的組件，也就是智能組件里，是不處理與view有關的東西，智能組件只處理數據和邏輯。而于視圖相關的東西全放在木偶組件去處理。好處是只要是邏輯處理，就會去找智能組件，而界面樣式之類，就會去找木偶組件，思路清晰，更低耦合高內聚。

組件

很多人對組件的理解是復用。其實組件化開發還有一個好處就是模塊化。模塊化可以將一個復雜的問題劃分為多個，簡單的問題去處理。打個比方你的能力一次只能處理一個七十分的問題，現在來了一個八十分的問題，你一次性很難處理，經常需要寫一寫，停頓一下，思考一會，然后再寫一寫，直至完成；相反如果你采用模塊化的方式去解決，直接將這個八十分的問題劃分為四個二十分的問題，此時，你只需要先搭建一個架子，讓這個四個二十分的模塊加起來能等于八十分，接著再去處理每個二十分的問題就OK了。這其實也秉承了自上而下的設計風格。
我通常將組件分為四類

智能組件

木偶組件

容器組件

高階組件

項目如果使用redux，智能組件通常是作為connect的那個組件，他只處理該組件下所有子組件的數據邏輯；而樣式，真實的dom結構，由木偶組件來負責，他通常是stateless function，偶爾也有自己的state，但即使是state，也只處理與頁面展示有關的邏輯；容器組件很簡單，如果把一個頁面比作一個人，容器組件就是人的頭，身體，和四肢。將頁面大致分類，通常的寫法是這樣的

//Body
{this.props.children}

ps：為什么容器組件不直接寫成div上文說過了。

如果說前三類組件都在為頁面服務，那么最后一個組件就是專門為組件服務的組件。高階組件就像高階函數一樣，將被修飾的組件作為參數，同時也可以傳入其他配置參數，最后返回一個被增強的組件，redux的connect就是一個高階組件，通常寫法是這樣的：

//高階組件
const Hoc = props => WrapComponent => {
  return class extends Component {
    render() {
      return ;
    }
  };
};
// 使用
class WrapComponent extends Component{
  render(){
    return 
  }
}
export default Hoc()(WrapComponent)

redux數據流

在redux數據流管理里，行業里有很多最佳實踐，我這里就當拋磚引玉。
我認為一般頁面邏輯不是很復雜的項目，簡單的使用redux redux-thunk redux-action就夠了，如果需要處理的請求很復雜，為了避免回調地獄，可以使用redux-saga。通常我們在對數據從頂部往下分發的時候，需要以一個維度為基點來做connect，這個維度一般是route頁面。對于router，現在也基本達成了共識，那就是router的數據狀態也是redux數據的一種，它與view無關，因此使用react-redux-router將router與redux結合在一起是一個比較好的做法。
在redux里，有一個比較有爭議的點是，關于頁面的狀態，是否要放在redux里。有人認為redux就應該只放數據，即后臺的數據和部分前臺自己存儲的數據；但是我認為，我們頁面在開發過程中，頁面的展示邏輯通常與后臺的數據是非常耦合的，可能一個按鈕的狀態，一個icon的顏色，都與后臺的數據有關，那么如果強行拆分，就會變成對于一個流程，我們要先去redux里處理后臺數據，處理好之后，再去智能組件里根據redux數據處理內部state（頁面的狀態），這樣很麻煩，也很難維護。我自己的做法是，每一個流程，只對應一個action，這個action內部再去根據不同的參數去處理不同的數據，直至頁面正常反應這個操作為止。

總結

總的來說，我們中很多人包括我自己，給view層賦予了太多的職能和責任，造成redux的價值沒有發揮出來，view里跑著各種state，后期難以維護，這無疑是本末倒置的。寫這篇總結也是對我最近寫項目的一些反思，希望能有更多的人一起討論，謝謝。

GPU云服務器云服務器單頁應用單頁應用cdn 單頁應用程序應用技巧總結

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/83327.html

Vue.js SSR 內容總結

摘要：本文只是對官方文檔和對官方的個人學習總結，說得不夠完整的請見諒本文主要對以下幾方面內容對的內容進行分析總結出現的原因的總體原理當中的數據預取在編寫代碼時候的限制的構建原理出現的原因單頁應用有一個很大的缺點就是問題，搜索引擎目前只能對同步的進本文只是對Vue.js官方SSR文檔和對官方hackernews demo的個人學習總結，說得不夠完整的請見諒本文主要對以下幾方面內容對Vue....

曹金海 2019-08-23 18:25 評論0 收藏0
在單頁應用中，如何優雅的監聽url的變化

摘要：單頁應用的原理從早起的根據的變化，到根據的的變化，實現無刷新條件下的頁面重新渲染。那么在單頁應用中是如何監聽的變化呢，本文將總結一下，如何在單頁頁面中優雅的監聽的變化。在下幾章中，重點介紹一下如何監聽的改變。 ??單頁應用的原理從早起的根據url的hash變化，到根據H5的history的變化，實現無刷新條件下的頁面重新渲染。那么在單頁應用中是如何監聽url的變化呢，本文將總結一下，...

leap_frog 2019-08-30 15:55 評論0 收藏0
在單頁應用中，如何優雅的監聽url的變化

摘要：單頁應用的原理從早起的根據的變化，到根據的的變化，實現無刷新條件下的頁面重新渲染。那么在單頁應用中是如何監聽的變化呢，本文將總結一下，如何在單頁頁面中優雅的監聽的變化。在下幾章中，重點介紹一下如何監聽的改變。 ??單頁應用的原理從早起的根據url的hash變化，到根據H5的history的變化，實現無刷新條件下的頁面重新渲染。那么在單頁應用中是如何監聽url的變化呢，本文將總結一下，...

姘存按 2019-08-02 14:00 評論0 收藏0
在單頁應用中，如何優雅的監聽url的變化

摘要：單頁應用的原理從早起的根據的變化，到根據的的變化，實現無刷新條件下的頁面重新渲染。那么在單頁應用中是如何監聽的變化呢，本文將總結一下，如何在單頁頁面中優雅的監聽的變化。在下幾章中，重點介紹一下如何監聽的改變。 ??單頁應用的原理從早起的根據url的hash變化，到根據H5的history的變化，實現無刷新條件下的頁面重新渲染。那么在單頁應用中是如何監聽url的變化呢，本文將總結一下，...

zhkai 2019-08-23 14:23 評論0 收藏0