React/Redux打造的同構Web應用

發表於2018-07-30

大家好，我是原一成(@herablog)，目前在CyberAgent主要擔任前端開發。

Ameblo（注: Ameba部落格，Ameba Blog，簡稱Ameblo）於2016年9月，將前端部分由原來的Java架構的應用，重構成為以node.js、React為基礎的Web應用。這篇文章介紹了本次重構的起因、目標、系統設計以及最終達成的結果。

新系統釋出後，立即就有人注意到了這個變化。

twitter_msg.png

系統重構的起因

2004年起，Ameblo成為了日本國內最大規模的部落格服務。然而隨著系統規模的增長，以及很多相關人員不斷追加各種模組、頁面引導連結等，最終使得頁面展現緩慢、對網頁瀏覽量(PV)造成了非常嚴重的影響。並且頁面展現速度方面，絕大多數是前端的問題，並非是後端的問題。

基於以上這些問題，我們決定以提高頁面展現速度為主要目標，對系統進行徹底重構。與此同時後端系統也在進行重構，將以往的資料部分進行API化改造。此時正是一個將All-in-one的巨型Java應用進行適當分割的絕佳良機。

目標

本次系統重構確立了以下幾個目標。

頁面展現速度的改善（總之越快越好）

用於測定使用者體驗的指標有很多，我們認為其中對使用者最重要的指標就是頁面展現速度。頁面展現速度越快，目標內容就能越快到達，讓任務在短時間內完成。這次重構的目標是儘可能的保持部落格文章、以及在Ameblo內所呈現的繁多的內容的固有形式，在不破壞現有價值、體驗的基礎上，提高展現和頁面行為的速度。

系統的現代化（搭乘生態系統）

從前的Web應用是將資料以HTML的形式返回，那個時候並沒有什麼問題。然而，隨著內容的增加，體驗的豐富化，以及裝置的多樣化，使得前端所佔的比重越來越大。此前要開發一個好的Web應用，如果要高效能，就一定不要將前後端分隔開。當年以這個要求開發的系統，在經歷了10年之後，已經遠遠無法適應當前的生態系統。

「跟上當前生態系統」，以此來構建系統會帶來許許多多的好處。因為作為核心的生態系統，其開發非常活躍，每天都會有許許多多新的idea。因而最新的技術和功能更容易被吸納，同時實現高效能也更加容易。同時，這個「新」對於年輕的技術新人也尤為重要。僅懂得舊規格舊技術的大叔對於一個優秀的團隊來說是沒有未來的（自覺本人膝蓋也中了一箭）。

升級介面設計、使用者體驗（2016年版Ameblo）

Ameblo的手機版在2010年經歷了一次改版之後，就基本上沒有太大的變化。這其間很多使用者都已經習慣了原生應用的設計和體驗。這個專案也是為了不讓人覺得很土很難用，達到順應時代的2016年版介面設計和使用者體驗。

OK，接下來讓我具體詳細聊聊。

頁面載入速度的改善

改善點

系統重構前，通過 SpeedCurve 進行分析，得出了下面結論：

伺服器響應速度很快
HTML文件較大（頁面所有要素都包含其中）
阻塞頁面渲染的資源（JavaScript、Stylesheet）較多
資源讀取的次數過多，體積過大

依據這些確定了下面這幾項基本方針：

為了不致於降低伺服器響應速度，對程式碼進行優化，快取等
儘可能減少HTML文件大小
JavaScript非同步地載入與執行
最初呈現頁面時，僅僅載入所需的必要資源

SSR還是SPA

近年來相比於新增到收藏夾中，使用者更傾向於通過搜尋結果、Facebook、Twitter等社交媒體上的分享連結開啟部落格頁面。Google和Twitter的AMP, Facebook的Instant Article表明第一頁的展現速度極大影響到使用者滿意度。

此外，從Google Analytics等日誌記錄中瞭解到在文章列表頁面和前後文章間進行跳轉的使用者也很多。這或許是因為部落格作為個人媒體，當某一使用者看到一篇不錯的文章，非常感興趣的時候，他也同時想看一看同一部落格內的其它文章。也就是說，部落格這種服務 第一頁快速載入與頁面間快速跳轉同等重要 。

因此，為了讓兩者都能發揮最佳效能，我們決定在第一頁使用伺服器端渲染（Server-side Rendering, SSR），從第二頁起使用單頁面應用（Single Page Application, SPA）。這樣一來，既能確保第一頁的展示速度和機器可讀性（Machine-Readability）（含SEO），又能獲得SPA帶來的快速展示速度。

BTW，對於目前的架構，由於伺服器和客戶端使用相同的程式碼，全部進行SSR或是全部進行SPA也是可能的。目前已經實現即便在不能執行JavaScript的環境中，也可以正常通過SSR來瀏覽。可以預見將來等到Service Worker普及之後，初始頁面將更加高速化，而且可以實現離線瀏覽。

z-ssrspa.png

以前的系統完全使用SSR，而現在的系統從第二頁起變為SPA。

z-spa-speed.gif

SPA的魅力在於呈現速度之快。因為僅僅通過API獲取所需的必要資料，所以速度非常快！

延遲載入

我們使用SSR+SPA的方法來優化頁面間跳轉這種橫向移動的速度，並且使用延遲載入來改善頁面的縱向移動速度。一開始要展現的內容以及導航，還有部落格文章等最早呈現，在這些內容之下的次要內容隨著頁面的滾動逐漸呈現。這樣一來，重要的內容不會受頁面下面內容的影響而更快的顯示出來。對於那些想盡快讀文章的使用者來說，既不增加使用者體驗上的壓力，又能完整的提供頁面下方的內容。

z-lazyload.png

之前的系統因為將頁面內的全部內容都放到HTML文件裡，所以使得HTML文件體積很大。而現在的系統，僅僅將主要內容放到HTML裡返回，減少了HTML的體積和資料請求的大小。

HTML快取

部落格文章是靜態文件，對於特定URL的請求會返回固定的內容，因此非常適合進行快取。快取使得伺服器處理內容減少，在提高頁面響應速度的同時減輕了伺服器的負擔。我們將不變的內容（文章等）生成的HTML進行快取返回，對於由於變化的內容能過JavaScript、CSS等進行操作（比如顯示、隱藏等）。

z-newrelic-entrylist.png

這張圖顯示了2016年9月最後一週New relic上的統計資料。文章列表頁面的HTML的響應時間基本在50ms以下。

z-newrelic-entry.png

這張圖是文章詳細頁面的統計資料。可以看出，這個頁面的響應時間也基本上是在50ms以下。由於存在文章過長的時候會造成頁面體積變大，以及文章頁面不能完全快取等情況，所以相比列表頁面會存在更多較慢的響應。

對於因請求的客戶端而產生變化部分的處理，我們在HTML的body標籤中通過加入相應的class，然後在客戶端通過JavaScript和CSS等進行操作。比如，一些內容不想在某些作業系統上顯示，我們就用CSS對這些內容進行隱藏。由於CSS樣式表會先載入，頁面佈局確定下來之後再進行頁面渲染，所以這個也可以解決後面要提到的「咯噔」問題。

<!-- html -->

<body class="OsAndroid">

/* main.css */

body.OsAndroid .BannerForIos {
  dsplay: none;
}

/* main.css */

body.OsAndroid .BannerForIos {

dsplay: none;

}

系統的現代化（搭乘生態系統）

技術選型

這次專案的技術選擇時，遵循了儘可能採用當前當前市場上已經存在的普遍使用的技術這一原則。暗號就是：「活脫脫像範例應用一樣Start」。這樣一來，無論是誰都可以輕鬆的獲取到相應的文件等資訊，同時其它的團隊和公司如果要參與到專案中來也能很快的上手。然而在真正進行開發的時候，一些細節實現上因為各種各樣的原因存在一些例外的情況，但是在極大程度上保持了各個模組的獨立性。最終系統的大體構成如下圖所示：

z-bigpicture.png

（有些地方做了省略）

React with Redux

使用React和React進行開發的的時候，很多地方可以用 純函式 的形式進行組合。純函式是指特定的引數總是返回特定的結果，不會對函式以外的範圍造成汙染。使用純函式進行開發可以保證各個處理模組最小化，不用擔心會無意間改變引用物件的值。這樣一來，十分有助於大規模開發以及在同一客戶端中維持多個狀態。

介面更新的流程是: Action(Event) -> Reducer (返回新的state(狀態)) -> React (基於更新後的store內的state更新顯示內容） 。

這是一個Redux Action的例子，演示了React Action (Action Creator) 基於引數返回一個Plain Object。處理非同步請求的時候，我們參考官方文件，分別定義了成功請求和失敗請求。獲取資料時使用了 redux-dataloader 。

// actions/blogAction.js

export const FETCH_BLOG_REQUEST = 'blog/FETCH_BLOG/REQUEST';

export function fetchBlogRequest(blogId) {
  return load({
    type: FETCH_BLOG_REQUEST,
    payload: {
      blogId,
    },
  });
}

// actions/blogAction.js

export const FETCH_BLOG_REQUEST = 'blog/FETCH_BLOG/REQUEST';

export function fetchBlogRequest(blogId) {

return load({

type: FETCH_BLOG_REQUEST,

payload: {

blogId,

});

}

Redux Reducer是一完全基於Action中攜帶的資料，對已有state進行復制並更新的函式。

// reducers/blogReducer.js

import  as blogAction from '../actions/blogAction';

const initialState = {};

function createReducer(initialState, handlers) {
  return (state = initialState, action) => {
    const handler = (action && action.type) ? handlers[action.type] : undefined;
    if (!handler) {
      return state;
    }
    return handler(state, action);
  };
}

export default createReducer(initialState, {
  [blogAction.FETCH_BLOG_SUCCESS]: (state, action) => {
    const { blogId, data } = action.payload;
    return {
      ...state,
      [blogId]: data,
    };
  },
});

// reducers/blogReducer.js

import as blogAction from '../actions/blogAction';

const initialState = {};

function createReducer(initialState, handlers) {

return (state = initialState, action) => {

const handler = (action && action.type) ? handlers[action.type] : undefined;

if (!handler) {

return state;

}

return handler(state, action);

};

}

export default createReducer(initialState, {

[blogAction.FETCH_BLOG_SUCCESS]: (state, action) => {

const { blogId, data } = action.payload;

return {

...state,

[blogId]: data,

};

});

React/Redux基於更新後的store中的資料，對UI進行更新。各個元件依據傳遞過來的props值，總是以相同的結果返回HTML。React將View元件也作為函式來對待。

// main.js
<SpBlogTitle blogTitle="渋谷のブログ" />

// SpBlogTitle.js
import React from 'react';

export class SpBlogTitle extends React.Component {
  static propTypes = {
    blogTitle: React.PropTypes.string,
  };

  shouldComponentUpdate(nextProps) {
    return this.props.blogTitle !== nextProps.blogTitle;
  }

  render() {
    return (
      <h1>{this.props.blogTitle}</h1>
    );
  }
}

// main.js

// SpBlogTitle.js

import React from 'react';

export class SpBlogTitle extends React.Component {

static propTypes = {

blogTitle: React.PropTypes.string,

};

shouldComponentUpdate(nextProps) {

return this.props.blogTitle !== nextProps.blogTitle;

}

render() {

return (

<h1>{this.props.blogTitle}</h1>

);

}

有關Redux的資訊在官方文件中說明得非常詳細，推薦隨時參考一下這個文件。

同構Web應用（Isomorphic web app）

Ameblo 2016年版基本上完全是用JavaScript重寫的。無論是Node伺服器上還是客戶端上都使用了相同的程式碼和流程，也就是所謂的同構Web應用。專案的目錄結構大體上如下所示，伺服器端的入口檔案是 server.js ，瀏覽器的入口檔案是 client.js 。

actions/ Redux Action （伺服器，客戶端共用）
api/ 封裝的API介面
components/ React元件（伺服器，客戶端共用）
reducer/ <span class=”underline”>Redux Reducers</span> (伺服器，客戶端共用）
services/ 服務層模型，使用 Fetchr 對資料請求進行適當粒度的劃分。同時這個也使得node.js作為代理，間接請求API（伺服器專用）。
server.js 伺服器入口（伺服器專用）
app.js node伺服器的配置、啟動，由server.js呼叫（伺服器專用）
client.js 客戶端入口（客戶端專用）

z-isomorphic.png

寫好的JavaScript同時執行在伺服器端還是客戶端上的執行行為、以及從資料讀取直到在頁面上顯示為止的整個瀏程，都以相同的形式進行。

React/Redux打造的同構Web應用

z-code-stats.png

使用Github的語言統計可以看出，JavaScript佔了整個專案的94.0%，幾乎全部都是由JavaScript寫成的。

原子設計（Atomic Design）

對於元件的規劃，我們採用了原子設計理念。其實專案並沒有一開始就採用原子設計，而是根據 Presentational and Container Components ，對 container 和 component 進行了兩層劃分。然而Ameblo中的元件實在是太多，很容易造成職責不明確的情況，因此最終採用了原子設計理念。專案的實際運用中，採用了以下的規則。

z-atomic-design.png

Atoms

元件的最小單位，比如Icon、Button等。原則上不具有狀態，從父元件中獲取傳遞過來的props，並返回HTML。

Molecules

以複用為前提的元件，比如List、Modal、User thunmbnail等。原則上不具有狀態，從父元件中獲取傳遞過來的props，並返回HTML。

Organisms

頁面上較大的一塊元件，比如Header，Entry，Navi等。對於這一層的元件，可以在其中進行資料獲取處理，以及使用Redux State 和 connect ，維護元件的狀態。這裡獲取的元件狀態以props的形式，傳遞給 Molecules 和 Atom 。

// components/organisms/SpProfile.js

import React from 'react';
import { connect } from 'react-redux';
import { routerHooks } from 'react-router-hook';

import { fetchBloggerRequest } from '../../../actions/bloggerAction';

// 資料獲取處理 (使用react-router-hook)
const defer = async ({ dispatch }) => {
  await dispatch(fetchBloggerRequest());
};

// Redu store的state作為props
const mapStateToProps = (state, owndProps) => {
  const amebaId = owndProps.params.amebaId;
  const bloggerMap = state.bloggerMap;
  const blogger = bloggerMap[amebaId];
  const nickName = blogger.nickName;

  return {
    nickName,
  };
};

@connect(mapStateToProps)
@routerHooks({ done })
export class SpProfileInfo extends React.Component {
  static propTypes = {
    nickName: React.PropTypes.string.isRequired,
  };

  render() {
    return (
      <div>{this.props.nickName}</div>
    );
  }
}

// components/organisms/SpProfile.js

import React from 'react';

import { connect } from 'react-redux';

import { routerHooks } from 'react-router-hook';

import { fetchBloggerRequest } from '../../../actions/bloggerAction';

// 資料獲取處理 (使用react-router-hook)

const defer = async ({ dispatch }) => {

await dispatch(fetchBloggerRequest());

};

// Redu store的state作為props

const mapStateToProps = (state, owndProps) => {

const amebaId = owndProps.params.amebaId;

const bloggerMap = state.bloggerMap;

const blogger = bloggerMap[amebaId];

const nickName = blogger.nickName;

return {

nickName,

};

@connect(mapStateToProps)

@routerHooks({ done })

export class SpProfileInfo extends React.Component {

static propTypes = {

nickName: React.PropTypes.string.isRequired,

};

render() {

return (

<div>{this.props.nickName}</div>

);

}

Template

各個請求路徑(URL)所對應的元件。其職責是將所需的部件從Organisms中import過來，以一定的順序和格式整合在一起。

Pages

作為頁面的頁面元件。基本上是把傳遞過來的 this.props.children 原原本本的顯示出來。由於Ameblo是單頁面應用，因而只有一個頁面元件。

CSS Modules

CSS樣式表使用 CSS Modules 將CSS樣式規則的作用範圍嚴格限制到了各個元件內。各個樣式規則的作用範圍進行限制使得樣式的變更和刪除更加容易。因為Ameblo是由許多人協同開發完成，不一定每個人都精通CSS，而且不免要時常對一些不知是誰何時寫的程式碼進行更改，在這個時候將作用範圍限制到元件的CSS Modules就發揮其作用了。

/ components/organisms/SpNavigationBar.css /

.Nav {
  background: #fff;
  border-bottom: 1px solid #e3e5e4;
  display: flex;
  height: 40px;
  width: 100%;
}

.Logo {
  text-align: center;
}

/ components/organisms/SpNavigationBar.css /

.Nav {

background: #fff;

border-bottom: 1px solid #e3e5e4;

display: flex;

height: 40px;

width: 100%;

}

.Logo {

text-align: center;

}

// components/organisms/SpNavigationBar.js

import React from 'react';
import style from './SpNavigationBar.css'

export class SpBlogInfo extends React.Component {
  render() {
    return (
      <nav className={style.Nav}>
        <div className={style.Logo}>
          <img
            alt="Ameba"
            height="24"
            src="logo.svg"
            width="71"
           />
        </div>
        <div ...>
      </nav>
    );
  }
}

// components/organisms/SpNavigationBar.js

import React from 'react';

import style from './SpNavigationBar.css'

export class SpBlogInfo extends React.Component {

render() {

return (

<img

alt="Ameba"

height="24"

src="logo.svg"

width="71"

</div>

</nav>

);

}

各個class的名稱經過webpack編譯之後，變成像 SpNavigationBar__Nav___3g5MH 這樣含hash值的全域性唯一名稱。

ESLint, stylelint

這次的專案將ESLint和stylelint放到了必須的位置，即便一個字母出錯，整個專案也無法測試通過。目的就在於統一程式碼風格，節約程式碼審查時的麻煩。具體規則分別繼承自 eslint-config-airbnb 和 stylelint-config-standard ，對於一些必要的細節做了少許定製。因為規則較嚴，起初的時候或許有點不便。新成員加入專案組時，程式碼通過Lint測試便成了要通過的第一關?。

z-code-review.png

防止了程式碼審查時對於這些細微寫法挑錯。被機器告知錯誤時，心理上會感覺稍好一些。

React/Redux打造的同構Web應用

z-ci-error.png

加入專案組之後，最初的這段時間裡發生Lint錯誤是常有的事。

CI, Build, Tesing

程式碼的構建、測試和部署統一使用CI（公司內部使用 CircleCI ）來完成。各個分支向GHE(Github Enterprise)PUSH之後，依據各個分支產生不同的動作。這個流程的好處就是構建相關的處理不需要專門人員來完成，而是統一寫在 circle.yml 和 package.json （node環境下）裡。

develop 開發（下次釋出）用分支。構建、測試之後自動部署到staging環境中。
release/vX.X.X 釋出分支。由develop分支派生，構建、測試之後，自動部署到semi（準生產）環境中。
hotfix/vX.X.X hotfix分支。由master分支派生，構建、測試之後，自動部署到semi（準生產）環境中。
deploy/${SERVER_NAME} 部署到分支所指定的相應伺服器上。主要是在開發環境中使用。
master 這個分支構建之後生成可以用於部署到production（生產）環境的docker映象。
其它 開發用分支。僅進行構建和測試。

Docker

本次系統重構，也對node.js應用進行docker化構建。這次重構的是前端系統，我們希望可以在細小修正之後立即進行部署。docker化之後，一旦將映象構建完成，可以不受node模組版本的左右進行部署，回滾也很容易。

此外，node.js本身釋出非常頻繁，如果放置不管，不知不覺之間系統就成古董了。docker化之後，可以不受各主機環境的影響自由的進行升級。

更重要的是，設定docker容器數是比較容易的，這對於系統橫向擴容以及對伺服器配置作優化時也十分方便。

升級介面設計、使用者體驗（2016年版Ameblo）

不再「咯噔」

系統重構之前的Ameblo由於存在一些高度沒有固定的模組，出現了「咯噔」現象。這種「咯噔」會導致誤點選以及頁面的重繪，十分令人厭煩。而此模組高度固定也做為本次系統重構的UI設計的前提。特別是頁面間導航作為十分重要的元素，我們經過努力使得在頁面跳轉時每次都可以觸擊到相同的位置。

React/Redux打造的同構Web應用

z-gatan.gif

「咯噔」的一個例子。點選[次のページ]（下一頁）的時候，額外的元素由於載入緩慢，造成誤點選。

z-paging-fixed.gif

系統重構之後，元素的位置被固定下來，減輕了頁面跳轉時給使用者心理上帶來的負擔。

智慧手機時代的使用者介面

2016年在移動環境下使用的使用者幾乎都在使用智慧手機。在智慧手機上，由於各個平臺的提供者制定了各自不同的使用者介面規範，使用者已經習慣並適應了使用者介面。相比之下，雖說瀏覽器上的規範非常少，但是如果和當今流行的介面差距太大的話，就會變得很難用。

Ameblo的手機版在2010年進行改版之後，自然對一些細節進行了改善，但是由於沒有太大的變動，所以現在看來很多地方已經給人一種很舊的印象。使用者在瀏覽的時候，對於介面並不區別是原生應用還是瀏覽器，因而製作出適應當前時代這個平臺的使用者介面顯得尤為重要。這裡介紹一下本次重構中，對於介面的一些升級。

z-update-design.png

內容佔據介面上橫向整個空間。2010年的時候，一般採用Twitter倡導的「將各個模組圈起來的設計」。

React/Redux打造的同構Web應用

z-searchbar.gif

增加了導航欄，把導航相關操作集中放置在這裡。

可訪問性

這次系統重構正值可訪問性成為熱點話題的時候。仔細的為HTML增加相當標籤屬生就可以使整個系統足夠可訪問。首先在HTML標籤屬性新增上時要用心斟酌。對於標題、 img 等新增適當的 alt 屬性，對於可點選的元素一定要使用 a button 等可點選的標籤。如果能自動對可訪問性進行檢驗就再好不過了，ESlint的 jsx-a11y 外掛可以幫助完成這一點。

在專案進行的時候，正好公司內開展了一次可訪問性的學習活動（ Designing Web Accessibility 的作者太田先生和伊原先生也參加了這次活動），在這次活動上也嘗試了Ameblo到目前為止沒有注意過的語音朗讀器。當時用語音朗讀器在Ameblo上進行朗讀時，有幾處有問題的地方，使用 WAI-ARIA 對這幾處加以修正（與 data-* 相同，JSX也支援 aria-* 屬性）。

這裡的PPT中有詳細的介紹，歡迎閱覽（日文）。

結果

OK，上面介紹了本次重構帶來的很多變化，那麼結果如何呢？

首先是效能相關指標（測試的URL都是Ameblo中單一頁面請求資源最多，展示速度最慢的頁面）。

阻塞渲染的資源（Critical Blocking Resources）

z-speed-blocking.png

阻塞渲染的資源數 減少了75% ！JavaScript全部變成了非同步讀取與執行。CSS樣式因為運營的原因，維持了重構前的狀態。

內容請求（Content Requests）

z-speed-requests.png

資源請求數 減少了58.04% ！由於使用了延遲載入，首屏顯示只載入必要的資源，與此同時對檔案進行適當的整理，並刪除了一些不必要的模組，最終達成了這個狀態。

渲染（Rendering）

z-speed-rendering.png

渲染速度做為前端的主要效能指標，本次 提升了44.68% 。

頁面載入時間（Page Load Time）

z-speed-pageload.png

頁面載入時間 縮短了40.5 ！此外，後端的返回時間也維持在了0.2ms ~ 0.3ms之間。

接下來介紹一下相關的業務指標。

網頁瀏覽量（Pageviews）

z-ga-pv.png

因為2016年9月有一位有名的部落格主成為了熱點話題，所以這個指標內含有特殊情況。網頁瀏覽量提升了57.15%。如果將熱點話題所帶來的數值除去後，實際上單純由系統重構所帶來的提升在10%到20%之間。

每次會話瀏覽頁數 (Pages / Session）

z-ga-pps.png

Pages / Session是指在單個會話內頁面的瀏覽數，這個指標 提升了35.54 。SPA改善了頁面間跳轉的速度，獲取了顯著的效果。

跳出率（Bounce Rate）

z-ga-bounce.png

跳出率指在一個會話內，僅看了一個頁面的比率，這個指標 改善了44.44% 。我們認為這是由於首屏和頁面跳轉速度的改善，使用者介面升級（更容易理解的分頁），「咯噔」改進所帶來的結果。

然而還存在很多改進的餘地，任何一個指標都可以再次提升。我們想以此表明 網站效能的提升會帶來業務指標的提升? 。

上述資料是在以下條件下取得的：

頁面效能
- 使用 SpeedCurve
- 測試的URL是 http://s.ameblo.jp/ebizo-ichikawa/entry-12152370365.html
- 瀏覽器指定為 Chrome, 53.0.2785.143移動端模擬模式
- 網路指定為4G模擬模式（14.6 Mbps，Upload 7.8Mbps，Latency 53ms）
業務指標
- 使用 Google Analytics
- 獲取自 s.ameblo.jp 內的全部資料
- 對2016年8月和2016年9月的數值進行比較

寫在最後

這次系統重構的出發點是對技術的挑戰，結果獲得了良好的使用者反饋，並對業務作出了貢獻，我們自身也感到非常有價值，獲得了極大的成就感。採用最新迎合時代潮流的技術自然提升服務的質量，也使得這種文化在公司在生根。在此，對及早匯入Isomorphic JavaScript，並向日本國內推廣的同事 @ahomu 表示感謝！? ?

作者介紹：

作者：原一成（Hara Kazunari），2008年加入日本CyberAgent公司。擔任Ameblo 2016移動前端改版專案總負責人。著有《GitHubの教科書》，《CSS3逆引きデザインレシピ》，《フロントエンドエンジニア育成読本》。

譯者：侯　斌（Hou Bin），2014年入職日本CyberAgent公司。現任Ameblo前端開發。在本次Ameblo 2016移動前端改版專案中擔任主要開發，負責基礎架構和技術選型以及關鍵模組開發等。

使用React做同構應用
2017-04-28
React
Isomorphic React（React同構應用）三：Bundle with Webpack
2016-12-18
ReactWeb
React 同構應用 PWA 升級指南
2018-05-25
React
如何構建一個WEB同構應用
2019-04-24
Web
打造可降級的React服務端同構框架
2019-03-02
React服務端框架
Redux + React 應用程式架構的 3 條規範（內附例項）
2016-12-23
ReduxReact架構
[譯] 測試 React & Redux 應用良心指南
2018-03-05
ReactRedux
讓react用起來更得心應手——（react-redux）
2019-03-04
ReactRedux
使用 React Hooks + Context 打造簡版 Redux
2019-04-04
ReactHookContextRedux
react同構實踐——實現自己的同構模板
2019-03-10
React
React+Redux仿Web追書神器
2017-12-15
ReactReduxWeb
Webpack實戰-構建同構應用
2017-12-19
Web
react、redux、react-redux之間的關係
2018-04-10
ReactRedux
React + Redux 做的OW組隊移動端Web
2017-12-18
ReactReduxWeb
從零開始搭建React應用（二）——React應用架構
2018-07-17
React應用架構
React+Redux 打造 “NEWS EARLY” 單頁應用一個專案理解最前沿技術棧真諦
2017-03-27
ReactRedux
Next.js部署web同構直出應用全指南（MobX + TypeScript）
2019-11-08
JSWebTypeScript
技術實踐丨React Native 專案 Web 端同構
2021-01-19
React NativeWeb
React 入門-redux 和 react-redux
2021-01-24
ReactRedux
react redux
2015-12-06
ReactRedux
打造一款可靠的WAF（Web應用防火牆）
2017-12-26
Web防火牆
web應用安全培訓教程之react
2019-08-02
WebReact
Node助力Web應用開發——在新的開發平臺，打造高效能Web應用
2012-02-24
Web
React,Redux,React-redux的錯綜複雜關係
2018-08-18
ReactRedux
以同構之名，再談 Redux/Vuex 的必要性
2017-12-18
ReduxVue
對React、Redux、React-Redux詳細剖析
2018-06-25
ReactRedux
React系列—React+Redux工程目錄結構劃分
2017-07-27
ReactRedux
【譯文】構建大型 Redux 應用的五個建議
2019-03-02
Redux
如何合理佈置React/Redux的目錄結構
2017-03-17
ReactRedux
React同構踩坑記錄
2018-04-23
React
React、Redux與複雜業務元件的複用
2017-09-10
ReactRedux元件
React應用架構設計指南
2017-12-30
React應用架構
React - React 中使用 Redux
2024-03-31
ReactRedux
構建單頁Web應用
2015-12-27
Web
react之redux的使用
2019-06-10
ReactRedux
react-redux 的使用
2019-07-08
ReactRedux
react-redux
2019-01-08
ReactRedux
基於 react, redux 最佳實踐構建的 2048
2017-10-12
ReactRedux

React/Redux打造的同構Web應用

系統重構的起因

目標

頁面展現速度的改善（總之越快越好）

系統的現代化（搭乘生態系統）

升級介面設計、使用者體驗（2016年版Ameblo）

頁面載入速度的改善

改善點

SSR還是SPA

延遲載入

HTML快取

系統的現代化（搭乘生態系統）

技術選型

React with Redux

同構Web應用（Isomorphic web app）

原子設計（Atomic Design）

Atoms

Molecules

Organisms

Template

Pages

CSS Modules

相關文章