最近在看ReactV16带来的新东西，V16版本直接支持了Portal。今儿就总结一下Portal这个自己不是那么熟悉却又非常重要的“传送门”吧。
先说说为什么需要传送门。React的世界一切皆组件，进行render就需要一个root根节点进行挂载。组件套组件一层一层，不过最外面一层都是挂在在这个root根节点上的。

有一个常见的需求Dialog(弹窗),通常它会显示在屏幕正中央，它应该是一个独立的组件。因此将这个弹窗组件放在根节点下的子组件里显然是不合适的。
我们希望将其渲染在和root根节点同级的DOM上在React组件树的最顶层。样式独立，没必要受其他组件的干扰。除了Dialog需要在最顶层渲染之外，我们还希望(也可以说是诉求)在不同的业务组件中去使用它。这里就需要Portal咯。

（ 天野喜孝展 ）

前一篇主要记录了一下SSR配置以及结合Redux的使用。这里简单说一下React SSR中样式处理和更优雅的SEO

SSR样式

在React客户端渲染，添加样式很容易。写一个css样式文件，在对应组件中引用。标签上通过className这个属性调用对应样式就万事Ok了。当然我们需要在webpack中配置loader来解析css文件。一般的配置如下（使用css modules）：

1
2
3
4
5
6
7
8
9
10
11
12
13

module: {
  rules: [{
    test: /\.css?$/,
    use: ['style-loader', {
      loader: 'css-loader',
      options: {
        importLoader: 1,
        modules: true,
        localIdentName: '[name]_[local]_[hash:base64:5]'
      }
    }]
  }]
}

需要先通过css-loader解析css文件，之后再通过style-loader将样式放在html的style标签中。

那么SSR也这样行吗~

1

yarn dev

跑一下服务，发现命令行报这个错误：

1
2
3
4

    return window && document && document.all && !window.atob;
    ^

ReferenceError: window is not defined

SSR已经不是什么新词、新概念了。为了解决React、Vue这类单页面（SPA）带来的首屏过慢以及SEO等问题随之而出。Vue、React官方也一直再跟进相关的支持。
同时社区也诞生了Next.js(React)以及Nuxt(vue)这类已经配置好，开箱即用的SSR解决方案。

之前在研究学习Webpack的时候，折腾过React SSR的配置和使用。从零配置Webpack4.0搭建一个React工程并且在蛮多自己瞎搞的项目中使用过，这几周自己再折腾SSR与Redux的结合。这一全面总结一下，就当温故知新了。

什么是服务端渲染/为什么使用服务端渲染

服务端渲染顾名思义浏览器通过url向服务器发送请求，服务器处理好页面的内容将整个页面返还给浏览器。每当请求一个url，服务器要将该url对应的页面内容发送给浏览器。

而SPA单页面应用则是在一开始一股脑将整个bundle.js加载进来。具体流程如下：

浏览器发送请求 -> 服务器返回HTML(空的骨架) -> 浏览器发送bundle.js -> 服务器返回bundle.js ->浏览器执行React/Vue代码

之后所有的url变成操作都通过这个js来处理，不需要再重新加载整个页面。web应用更具响应性，用户体验更好。但是由于一开始要加载一大坨bundle.js就会带来首屏过慢的问题。由于整个网页的内容都在js中，自然而然html源码什么都没有，不利于SEO。

为了解决痛点SSR就来了。它不是传统意义的服务端渲染，只是首屏渲染，首屏通过服务器直接生成，之后的由客户端（浏览器）接管。这样既能解决首屏速度、SEO还能同事拥有单页面应用带给用户的流畅性。(这里有一个专有名词叫做：同构–一套代码在服务器执行一遍，在客户端执行一遍) 具体流程如下：

浏览器发送请求 -> 服务器运行React代码生成页面 -> 服务器返回页面 -> 浏览器加载bundle.js -> bundle.js的React代码在浏览器重新执行 -> bundle.js的React重新接管页面操作。

这里主要说说React中的SSR核心由于虚拟DOM的存在(真实DOM的JS对象映射)
在SPA中

1

ReactDom.render(<Home />, id/root)

在SSR中虚拟dom的存在让SSR变得很简单

1

renderToString(<Home />)

把虚拟dom转化为字符串，返给服务器就是了

最近一个月，主要的精力还是在小程序这边，公司的项目是，自己闲暇之余写的小项目也是。
公司项目就不说了，自己的小项目涙曇
前后用了一个月，101commits完成了1.0.0版。从有想法到自己设计再到开发完完全全走完这一套流程，还是很满足的。

这里还是聊聊最近编写小程序一些问题和解决方案

（中秋在三里屯人行天桥拍到的日落，很美）

小程序在微信这个超级平台的带动下，这两年着实是越来越火。刚出来那一阵，翻了翻文档简单的看了看，没有组件、没有wsx(虽然现在也很难用，有总比没有强)还有无穷无尽的坑。一直没有深入去学习去了解。期间美团开源了一个mpvue，一个基于Vue的小程序开发框架。上手没什么成本，自己写了一个极其简单简陋查询快递的小程序–快递去哪儿咯。最近工作上来了小程序的需求，组内交流之后打算用小程序原生的那一套搞。现学现搞all in了两周小程序。这里记录一下遇到的一些小问题或者坑吧。

吐槽

那我们就从吐槽开始

（很喜欢的一部电影）

上篇博文至今，又间隔了一个多月。其实这一个月自我感觉成长了不少，学到也用到了不少东西。一直懒于动笔拖到了七月的尾巴。

工作上

工作上正式开搞了一个新项目。前端这边React全家桶。React全家桶无非就那点东西，但这回确实收获了不少。最大的收获还是工程化和拆分这一块。之前自己写前端项目亦或是在无二写RN回头来看离工程化差的好远，这次的工作才真真切切感受到了什么是前端工程。

在这次工作中，在等待后端提供接口的时间，首先做了一个纯JS的组件库，组件库分通用组件和逻辑组件两种。一开始自己不太理解已经有Antd这样UI组件库，为什么还要自己搞一套。和老大请教之后给出的解释是这样的我们所做的后台之后还会面向C端，与其用一个大而全的开源项目修改，不如一点点完善一个小项目，可以避免很多冗余的代码同时项目不仅仅只是纯UI组件还会有很多业务强相关的组件，先完善搞好组件之后正式开发项目在页面上甩组件就是咯。

在组件库开发过程中，为了方便开发，使用了Storybook这个神器。Storybook可以说是一个UI组件的开发环境,很方便的去交互测试组件，以及生成组件文档。其实官方文档也相当清楚。正如它页面展示的动图一样，交互体验去开发组件，调试测试都很方面。这里暂时不展开说了了，后续专门写一篇介绍一下。样式组件之外就是和业务强关联的业务组件。自己在这一块的开发做的不是很好，没有想清业务便着手开发在之后项目使用中，发现这里有不足那里有不足返工添加属性逻辑反反复复好几次。以后还是要先想好理清楚之后再coding。

组件库做得差不多了、后端API也开发完毕了终于到了项目开发，总体来说有了组件库的开发铺垫，正式开发起来非常效率。
在豆瓣工作最直观的感受就是工作上的任务、文档清晰明了，所有研发都心照不宣地维护这个传统和文化，这点真的很难得。提issue讨论确定需求，projects任务排期。开发之后提PR，同事仔细地Review代码，最后同事的一句LGTM结束这个PR的开发。这一系列看似理所因当的，规范的流程操作，在国内快文化下太难得了。

回到前端工程上来，首先是项目拆分的很细致。就说Redux这一块actions、const、effect、reducer、sagas、store(这里是之后一个文件configure-store.js进行redux的一些配置包括区分开发和生产环境以及saga的配置)足足有六个文件夹。一开始上手的时候很懵逼，不过确实很清晰。自己在工作之余的学习中，自己的那个项目也完全按工作中的细化规模自己实践了一番。Redux虽说繁琐，不过真正搞清楚Redux工作流，熟练上手之后。Redux这种清晰的数据变化流程不要太赞。我认为Redux最能提升的不是开发效率，而是维护效率。这就是Redux的可预测性吧。再有就是从同事的代码上学到了好多，在之前的公司完全没有这种感受，自己还是要加油

公司的react项目，在管理异步action这一块，都用的是redux-saga这个中间件。之前自己在做项目/练习的时候，都是用redux-thunk这个比起saga轻量很多的解决方案。
这两天正好在学习和摸索redux-saga。顺便总结一下。

redux-thunk/redux-saga

首先redux-thunk和redux-saga都是redux的中间件，目的是解决redux应用中的异步问题。redux本身是不支持异步的，action creator直接返回一个对象。这里redux-thunk通过十几行代码，判断action creator函数返回的是不是一个对象，不是对象是函数的话再用dispatch发出去。之前自己写过一个简单的redux-thunk的模拟。大致就是这样的

1
2
3
4
5
6
7
8
9
10

const thunk = ({dispatch, getState}) => next => action => {
  // 如果是函数，执行以下；参数是dispatch和getState
  if (typeof action === 'function') {
    return action(dispatch, getState)
  }
  // 啥事没干 原样返回
  return next(action)
}
export default thunk

redux-saga也是解决同样的问题，但是redux-saga是通过在redux原有的数据流中再加了一层，对action进行监听。捕获到监听的Action后可以派生一个新的任务对state进行维护，更改state来驱动view层变化。saga和thunk都是可以处理异步操作和协调复杂的dispatch。不同额是thunk是在action创建的时候才调用，saga是在应用入口就启动了，一直在监听action，并作出相应处理。说白了就是saga将所有的异步操作逻辑收集在一个地方集中处理。相比thunk的处理方式，更能剥离redux应用的副作用，让数据处理更加优雅（也更加麻烦=。=）

saga核心原理是利用了generator，使异步操作流程更加优雅。sagas都是用Generator函数实现的。

• 以generator形式组织逻辑序列（function* + yield），把一系列的串行/并行操作通过yield拆分开
• 利用iterator的可“暂停/恢复”特性（iter.next()）分步执行
• 通过iterator影响内部状态（iter.next(result)），注入异步操作结果
• 利用iterator的错误捕获特性（iter.throw(error)），注入异步操作异常

使用

下面说说怎么引入redux-saga

1
2
3
4
5
6
7
8
9
10
11
12

import { createStore, applyMiddleware } from 'redux'
import createSagaMiddleware from 'redux-saga'
//引入saga文件
import { rootSaga } from './rootSaga'
//使用 redux-saga 模块的 createSagaMiddleware 工厂函数来创建一个 Saga middleware。
//运行 rootSaga 之前，我们必须使用 applyMiddleware 将 middleware 连接至 Store。然后使用 

const sagaMiddleware = createSagaMiddleware()
const middlewares = [ sagaMiddleware ]

const store = createStore(rootReducer, applyMiddleware(...middlewares))
sagaMiddleware.run(rootSaga)

（上海·凌空SOHO）

React性能优化：

性能优化老生常谈，网上的文章也一大堆，自己总结一下，也做一个记录。

1）单组件：传递参数要少传，尽可能减少React在传递参数时候的负担。当然在使用数据的时候尽可能使用一份数据，而不是重新定义一份。

在使用 函数的时候：

NG：

每次执行render函数的时候bind都会执行一次

1

<button onClick={this.handleClick.bind(this)}></button>

比上一个好一点，但每次执行render的时候都会重新生成一个函数

1

<button onClick={() => this.handleClick()}></button>

Good：

1
2
3
4

constructor(props) {
  super(props)
  this.handleClick = this.handleClick.bind(this) // 构造函数只会执行一次。在构造函数中绑定this
}

1

<button onClick={this.handleClick}></button>