前言

本文是基于react ssr的入门教程，在实际项目中使用还需要做更多的配置和优化，比较适合第一次尝试react ssr的小伙伴们。技术涉及到 koa2 + react，案例使用create-react-app创建。

客户端渲染与服务端渲染

客户端渲染

• 客户端渲染，实际上就是客户端向服务端请求页面，服务端返回的是一个非常简单的 HTML 页面，在这个页面里，只有很少的一些 HTML 标签
• 客户端渲染时，页面中有两个比较重要的点，第一个是 script 标签，可能会有好几个 script 标签，这个标签是打包后的 js 代码，用来生成 DOM 元素，发送请求，事件绑定等。但是，生成的 DOM 元素需要有一个在页面上展示的容器，所以另外一个点就是容器，一般是一个 id 名为 root 或 app 的 div 标签，类似于这样 <div id="root"></div> 或<div id="app"></div>
• 客户端渲染的特点
  • 客户端加载所有的 js 资源，渲染 DOM 元素
  • 在浏览器页面上的所有资源，都由客户端主动去获取，服务端只负责静态资源的提供和 API 接口，不再负责页面的渲染，如果采用 CDN 的话，服务端仅仅需要提供 API 接口
  • 优点: 前后端分离，责任区分，前端专注页面的开发，后端专注接口的开发
  • 缺点: 首屏加载资源多，首屏加载时响应慢。页面上没有 DOM 元素，不利于 SEO 优化

服务端渲染

• 服务端渲染，就是客户端页面上的 HTML 元素，都要由服务端负责渲染。服务端利用模板引擎，把数据填充到模板中，生成 HTML 字符串，最终把 HTML 字符串返回到浏览器，浏览器接收到 HTML 字符串，通过 HTML 引擎解析，最终生成 DOM 元素，显示在页面上
• 比如 Node.js 可以渲染的模板引擎有 ejs，nunjucks，pug 等。Java 最常见的是 JSP 模板引擎。Python 最常见的是 Jinja2 模板引擎。
• 服务端渲染的特点
  • 优点: 页面资源大多由服务端负责处理，所以页面加载速度快，缩短首屏加载时间。有利于 SEO 优化。无需占用客户端资源
  • 缺点: 不利于前后端分离，开发效率低。占用服务器资源

区分与选择

• 客户端渲染和服务端渲染本质的区别就是，是谁负责 HTML 页面的拼接，那么就是谁渲染的页面
• 如果对首屏加载时间有非常高的需求，或者是需要 SEO 优化，那么就选择服务端渲染
• 如果对首屏加载时间没有要求，也不需要做 SEO 优化，类似于做后台管理系列的业务，那么就可以选择客户端渲染
• 具体选择客户端渲染还是服务端渲染，没有强制的要求，具体要根据项目的需求来区分选择

Docker，是一款现在最流行的 软件容器平台，提供了软件运行时所依赖的环境。

物理机

硬件环境，真实的 计算机实体，包含了例如物理内存，硬盘等等硬件；

虚拟机:

在物理机上 模拟出一套硬件环境和操作系统，应用软件可以运行于其中，并且毫无感知，是一套隔离的完整环境。本质上，它只是物理机上的一份运行文件。

为什么需要虚拟机？

环境配置与迁移

在软件开发和运行中，环境依赖一直是一个很头疼的难题，比如你想运行 node 应用，那至少环境得安装 node 吧，而且不同版本，不同系统都会影响运行。解决的办法就是我们的包装包中直接包含运行环境的安装，让同一份环境可以快速复制到任意一台物理机上。

资源利用率与隔离

通过硬件模拟，并包含一套完整的操作系统，应用可以独立运行在虚拟机中，与外界隔离。并且可以在同一台物理机上，开启多个不同的虚拟机启动服务，即一台服务器，提供多套服务，且资源完全相互隔离，互不影响。不仅能更好提高资源利用率率，降低成本，而且也有利于服务的稳定性。

传统虚拟机的缺点

资源占用大

由于虚拟机是模拟出一套完整系统，包含众多系统级别的文件和库，运行也需要占用一部分资源，单单启动一个空的虚拟机，可能就要占用 100+MB 的内存了。

启动缓慢

同样是由于完整系统，在启动过程中就需要运行各种系统应用和步骤，也就是跟我们平时启动电脑一样的耗时。

冗余步骤多

系统有许多内置的系统操作，例如用户登录，系统检查等等，有些场景其实我们要的只是一个隔离的环境，其实也就是说，虚拟机对部分需求痛点来说，其实是有点过重的。

Linux 容器

Linux 中的一项虚拟化技术，称为 Linux 容器技术(LXC)。它在进程层面模拟出一套隔离的环境配置，但并没有模拟硬件和完整的操作系统。因此它完全规避了传统虚拟机的缺点，在启动速度，资源利用上远远优于虚拟机；

定义：轻量级、高性能的 Web 服务器，在现今的大型应用、网站基本都离不开 Nginx，已经成为了一项必选的技术；其实可以把它理解成 入口网关。

当你去银行办理业务时，刚走进银行，需要到入门处的机器排队取号，然后按指令到对应的柜台办理业务，或者也有可能告诉你，今天不能排号了，回家吧！ 这样一个场景中，取号机器就是 Nginx(入口网关)。一个个柜台就是我们的业务服务器(办理业务)；银行中的保险箱就是我们的数据库(存取数据)；🤣

特点

1. 轻量级，配置方便灵活，无侵入性；
2. 占用内存少，启动快，性能好；
3. 高并发，事件驱动，异步；
4. 热部署，修改配置热生效；

随着 Web技术 和 移动设备 的快速发展，在各家大厂中，Hybrid 技术已经成为一种最主流最不可取代的架构方案之一。一套好的 Hybrid 架构方案能让 App 既能拥有极致的体验和性能，同时也能拥有Web技术灵活的开发模式、跨平台能力以及热更新机制。因此，相关的 Hybrid 领域人才也是十分的吃香，精通Hybrid 技术和相关的实战经验，也是面试中一项大大的加分项。

混合方案简析

Hybrid App，俗称 混合应用，即混合了 Native技术 与 Web技术 进行开发的移动应用。现在比较流行的混合方案主要有三种，主要是在UI渲染机制上的不同:

Webview UI

通过 JSBridge 完成 H5 与 Native 的双向通讯，并 基于 Webview 进行页面的渲染；

优势: 简单易用，架构门槛/成本较低，适用性与灵活性极强；

Webview 性能局限，在复杂页面中，表现远不如原生页面；

Native UI

通过 JSBridge 赋予 H5 原生能力，并进一步将 JS 生成的虚拟节点树(Virtual DOM)传递至 Native 层，并使用 原生系统渲染。

优势: 用户体验基本接近原生，且能发挥 Web技术 开发灵活与易更新的特性；

上手/改造门槛较高，最好需要掌握一定程度的客户端技术。相比于常规Web开发，需要更高的开发调试、问题排查成本；

小程序

通过更加定制化的 JSBridge，赋予了 Web 更大的权限，并使用双 WebView 双线程的模式隔离了 JS逻辑 与 UI渲染，形成了特殊的开发模式，加强了 H5 与 Native 混合程度，属于第一种方案的优化版本；

优势: 用户体验好于常规 Webview 方案，且通常依托的平台也能提供更为友好的开发调试体验以及功能；

劣势: 需要依托于特定的平台的规范限定

Immer 中文文档

前言

Immer 是 mobx 的作者写的一个 immutable 库，核心实现是利用 ES6 的 proxy，几乎以最小的成本实现了 js 的不可变数据结构，简单易用、体量小巧、设计巧妙，满足了我们对JS不可变数据结构的需求。
无奈网络上完善的文档实在太少，所以自己写了一份，本篇文章以贴近实战的思路和流程，对 Immer 进行了全面的讲解。

目录

• 数据处理存在的问题
• 解决引用类型对象被修改的办法
• immer功能介绍
  • 安装immer
  • immer如何fix掉那些不爽的问题
  • 概念说明
  • 常用api介绍
• 用immer优化react项目的探索
  • 抛出需求
  • 优化setState方法
  • 优化reducer
• 参考文档

在处理表单登录的过程中，遇到了一个问题，当我们在输入框输入内容输入框获取到焦点时，输入框后面会出现一个图标删除已输入的内容，因此删除图标会绑定一个click事件，但是当我们点击图标的时候，也触发了input的blur事件，blur事件会让input失去焦点时隐藏删除的图标，并且blur事件先于图标的click事件执行，因此这时候点击图标并不会删除输入框已输入的内容，而是图标消失了。还有弹窗输入框blur同时点击取消按钮关闭，也会出现需要点击2次的情况。