React 18 发布、Vue 3、Vitest、Pinia 正式成为 Vue 官方推荐的状态

Pinia 终于转正了，它具有与 Vuex 5 几乎完全相同或者增强的 API，简单来说，它就是和 Vuex 5 名字不同。Vuex 3 和 4 仍会继续维护，但是新功能不太可能会添加了。Pinia 也支持渐进式迁移，Vuex 和 Pinia 可以安装在同一个项目中，新项目的话建议直接使用 Pinia。

Vite 发布了 v290。

React 18 终于发布了，官方团队从 v16 就开始普及并发概念，到正式版发布时难免少了一些新鲜感。照目前的发展趋势看，React 未来会朝着前端底层“操作系统”的方向发展，会变得越来越复杂。这些复杂的操作又会被元框架(Nextjs、Remix)消化掉，开发者并不会直接接触，使用这些元框架开发即可。

稳定不停滞，支持增量升级，v5、v6 的版本代码可以同时存在。

下面是其他的发布信息和 TC39 提案的一些推进情况，大家可以找感兴趣的自行查阅。

下面我们来看技术资料。

和好朋友卡颂一起在做的项目： 前端赏金猎人 。

这是一个用单纯的金钱关系维系的前端学习社区，悬赏答题 + 答题赚钱。

期待你的加入，如果觉得有价值的话，可以给个 Star 鼓励一下。

把技术名词的大小写拼写正确是基本的素养，但很多人都不重视，这个项目可以帮助你纠正错误的大小写。

免费的编程中文书籍索引，项目已有 901k Star。

从 2008 年谷歌浏览器推出至今的 100 个精彩瞬间回 忆录。

在这里插入描述

Pinia 是 Vuejs 的轻量级状态管理库，最近很受欢迎。它使用 Vue 3 中的新反应系统来构建一个直观且完全类型化的状态管理库。

Pinia的成功可以归功于其管理存储数据的独特功能（可扩展性、存储模块组织、状态变化分组、多存储创建等）。

另一方面，Vuex也是为Vue框架建立的一个流行的状态管理库，它也是Vue核心团队推荐的状态管理库。 Vuex高度关注应用程序的可扩展性、开发人员的工效和信心。它基于与Redux相同的流量架构。

在这篇文章中，我们将对Pinia和Vuex进行比较。我们将分析这两个框架的设置、社区优势和性能。我们还将看一下Vuex 5与Pinea 2相比的新变化。

Pinia 设置

Pinia 很容易上手，因为它只需要安装和创建一个store。

要安装 Pinia，您可以在终端中运行以下命令：

该版本与Vue 3兼容，如果你正在寻找与Vue 2x兼容的版本，请查看v1分支。

Pinia是一个围绕Vue 3 Composition API的封装器。因此，你不必把它作为一个插件来初始化，除非你需要Vue devtools支持、SSR支持和webpack代码分割的情况：

在上面的片段中，你将Pinia添加到Vuejs项目中，这样你就可以在你的代码中使用Pinia的全局对象。

为了创建一个store，你用一个包含创建一个基本store所需的states、actions和getters的对象来调用 defineStore 方法。

Vuex 也很容易设置，需要安装和创建store。

要安装Vuex，您可以在终端中执行以下命令：

要创建store，你可以使用包含创建基本store所需的states、actions和 getter 的对象调用 createStore 方法：

要访问 Vuex 全局对象，需要在 Vuejs 项目根文件中添加 Vuex，如下所示：

使用 Pinia，可以按如下方式访问该store：

请注意，在访问其属性时省略了 store 的 state 对象。

使用Vuex，可以按如下方式访问store：

这两个状态管理库都相当容易学习，因为它们在 YouTube 和第三方博客上都有很好的文档和学习资源。对于以前有使用 Redux、MobX、Recoil 等 Flux 架构库经验的开发人员来说，他们的学习曲线更容易。

这两个库的文档都很棒，并且以对经验丰富的开发人员和新开发人员都友好的方式编写。

Pinia和Vuex都非常快，在某些情况下，使用Pinia的web应用程序会比使用Vuex更快。这种性能的提升可以归因于Pinia的极轻的重量，Pinia体积约1KB。

尽管Pinia是在Vue devtools的支持下建立的，但由于Vue devtools没有暴露出必要的API，所以一些功能如时间旅行和编辑仍然不被支持。当开发速度和调试对你的项目来说更重要时，这是值得注意的。

Pinia 将这些与 Vuex 3 和 4 进行了比较：

这些是Pinia在其状态管理库和Vuex之间的比较中提出的额外见解：

将 Pinia 2（目前处于 alpha 阶段）与 Vuex 进行比较，我们可以推断出 Pinia 领先于 Vuex 4。

Vuejs核心团队为Vuex 5制定了一个开放的RFC，类似于Pinia使用的RFC。目前，Vuex通过RFC来尽可能多地收集社区的反馈。希望Vuex 5的稳定版本能够超越Pinea 2。

据同时也是 Vuejs 核心团队成员并积极参与 Vuex 设计的 Pinia 的创建者（Eduardo San Martin Morote）所说，Pania 和 Vuex 的相似之处多于不同之处：

尽管 Pinia 足以取代 Vuex，但取代 Vuex 并不是它的目标，因此 Vuex 仍然是 Vuejs 应用程序的推荐状态管理库。

根据我的个人经验，由于Pinea是轻量级的，体积很小，它适合于中小型应用。它也适用于低复杂度的Vuejs项目，因为一些调试功能，如时间旅行和编辑仍然不被支持。

将 Vuex 用于中小型 Vuejs 项目是过度的，因为它重量级的，对性能降低有很大影响。因此，Vuex 适用于大规模、高复杂度的 Vuejs 项目。

批处理是 React将多个状态更新分组到单个重新渲染中以获得更好的性能。

例如，如果你在同一个点击事件中有两个状态更新，React 总是将它们分批处理到一个重新渲染中。如果你运行下面的代码，你会看到每次点击时，React 只执行一次渲染，尽管你设置了两次状态：

这对性能非常有用，因为它避免了不必要的重新渲染。它还可以防止你的组件呈现仅更新一个状态变量的“半完成”状态，这可能会导致错误。

这可能会让你想起餐厅服务员在你选择第一道菜时不会跑到厨房，而是等你完成订单。

然而，React 的批量更新时间并不一致。例如，如果你需要获取数据，然后更新handleClick上面的状态，那么 React不会批量更新，而是执行两次独立的更新。

这是因为 React 过去只在浏览器事件（如点击）期间批量更新，但这里我们在事件已经被处理（在 fetch 回调中）之后更新状态：

在 React 18 之前，我们只在 React 事件处理程序期间批量更新。默认情况下，React 中不会对 promise、setTimeout、本机事件处理程序或任何其他事件中的更新进行批处理。

从 React 18 开始createRoot，所有更新都将自动批处理，无论它们来自何处。

这意味着超时、承诺、本机事件处理程序或任何其他事件内的更新将以与 React 事件内的更新相同的方式进行批处理。

我们希望这会导致更少的渲染工作，从而在你的应用程序中获得更好的性能：

注意：作为采用 React 18 的一部分，预计你将升级到createRoot。旧行为的render存在只是为了更容易地对两个版本进行生产实验。

无论更新发生在何处，React 都会自动批量更新，因此：

行为与此相同：

通常，批处理是安全的，但某些代码可能依赖于在状态更改后立即从 DOM 中读取某些内容。对于这些用例，你可以使用ReactDOMflushSync()选择退出批处理：

2、Suspense 的 SSR 支持

这基本上是服务器端渲染 (SSR) 逻辑的扩展。在典型的 React SSR 应用程序中，会发生以下步骤：

典型 SSR 应用程序的问题在于，在下一步可以开始之前，必须立即完成整个应用程序的每个步骤。这会使您的应用程序在初始加载时变慢且无响应。

React 18 正试图解决这个问题。 组件已经以这样的方式进行了革命性的改变，它将应用程序分解为更小的独立单元，这些单元经过提到的每个步骤。这样一旦用户看到内容，它就会变成互动的。

我们将状态更新分为两类：

单击、悬停、滚动或打字等紧急更新需要立即响应以匹配我们对物理对象行为方式的直觉。否则他们会觉得“错了”。

然而，转换是不同的，因为用户不希望在屏幕上看到每个中间值。

例如，当您在下拉列表中选择过滤器时，您希望过滤器按钮本身在您单击时立即响应。但是，实际结果可能会单独转换。

一个小的延迟是难以察觉的，而且通常是预料之中的。如果在结果渲染完成之前再次更改过滤器，您只关心看到最新的结果。

在典型的 React 应用程序中，大多数更新在概念上都是过渡更新。但出于向后兼容性的原因，过渡是可选的。

默认情况下，React 18 仍然将更新处理为紧急更新，您可以通过将更新包装到startTransition

构建流畅且响应迅速的应用程序并不总是那么容易。有时，诸如单击按钮或输入输入之类的小动作可能会导致屏幕上发生很多事情。这可能会导致页面在所有工作完成时冻结或挂起。

例如，考虑在过滤数据列表的输入字段中键入。您需要将字段的值存储在 state 中，以便您可以过滤数据并控制该输入字段的值。您的代码可能如下所示：

在这里，每当用户键入一个字符时，我们都会更新输入值并使用新值来搜索列表并显示结果。

对于大屏幕更新，这可能会导致页面在呈现所有内容时出现延迟，从而使打字或其他交互感觉缓慢且无响应。

即使列表不是太长，列表项本身也可能很复杂并且每次击键时都不同，并且可能没有明确的方法来优化它们的呈现。

从概念上讲，问题在于需要进行两种不同的更新。第一个更新是紧急更新，用于更改输入字段的值，以及可能会更改其周围的一些 UI。

第二个是显示搜索结果的不太紧急的更新。

用户希望第一次更新是即时的，因为这些交互的本机浏览器处理速度很快。但是第二次更新可能会有点延迟。

用户不希望它立即完成，这很好，因为可能有很多工作要做。（实际上，开发人员经常使用去抖动等技术人为地延迟此类更新。）

在 React 18 之前，所有更新都被紧急渲染。

这意味着上面的两个状态仍然会同时呈现，并且仍然会阻止用户看到他们交互的反馈，直到一切都呈现出来。我们缺少的是一种告诉 React 哪些更新是紧急的，哪些不是的方法。

新startTransitionAPI 通过让您能够将更新标记为“转换”来解决此问题：

包装在其中的更新startTransition被视为非紧急处理，如果出现更紧急的更新（如点击或按键），则会中断。

如果用户中断转换（例如，连续输入多个字符），React 将抛出未完成的陈旧渲染工作，仅渲染最新更新。

Transitions 可让您保持大多数交互敏捷，即使它们导致显着的 UI 更改。它们还可以让您避免浪费时间渲染不再相关的内容。

上述问题的一个常见解决方案是将第二次更新包装在 setTimeout 中：

这将延迟第二次更新，直到呈现第一次更新之后。节流和去抖动是这种技术的常见变体。

一个重要的区别是startTransition不安排在以后喜欢的setTimeout是。它立即执行。传递给的函数startTransition同步运行，但其中的任何更新都标记为“转换”。

React 将在稍后处理更新时使用此信息来决定如何呈现更新。这意味着我们比在超时中包装更新更早地开始呈现更新。

在快速设备上，两次更新之间的延迟非常小。在较慢的设备上，延迟会更大，但 UI 会保持响应。

另一个重要的区别是 a 内的大屏幕更新setTimeout仍然会锁定页面，只是在超时之后。

如果用户在超时触发时仍在键入或与页面交互，他们仍将被阻止与页面交互。但是标记为 的状态更新startTransition是可中断的，因此它们不会锁定页面。

它们让浏览器在呈现不同组件之间的小间隙中处理事件。

如果用户输入发生变化，React 将不必继续渲染用户不再感兴趣的内容。

最后，因为setTimeout只是延迟更新，显示加载指示器需要编写异步代码，这通常很脆弱。

通过转换，React 可以为您跟踪挂起状态，根据转换的当前状态更新它，并让您能够在用户等待时显示加载反馈。

您可以使用startTransition来包装要移动到后台的任何更新。通常，这些类型的更新分为两类：

总结

React 18 没有任何重大更改，因此，我们将当前的存储库升级到最新版本几乎不需要更改代码，但我们可以享受它们很酷的功能。

一个 React 组件可以简单地被认为是返回元素的函数（或者至少有一个具有这样的功能的类）。 这种功能性方法对于 Javascript 开发人员是非常自然的。 传入数据，得到元素。 如果你有一堆内容在数组当中，你可以简单地将它们遍历出一系列元素。 如果你想排除这些项目中的某一些元素，你可以使用 Array 数组对象中的 filter 方法和 map 方法去处理元素并且得到结果。这个功能性工作流程完美地反映了您对应用程序的其他部分的理解。 这种方法是对Javascript的优势的补充。一个 Vue 组件更像是一个能够从数据结构当中引用数据的模板。它包含了一个 DSL（Domain specific language），虽然是次要的，但是显然是完全没有必要的。我不需要 v-for 因为我可以使用 map()。我不需要 v-if 因为我可以使用普通的老旧的 if。模板至少会带来一定程度的有限或无益的认知压力。模板还引入了作用域的问题。 如果我将一些静态数据导入到我的 React 组件中，我可以在我的渲染函数中使用它，因为所有标准的 JavaScript 作用域规则都应用于此。 它只是一个 函数，与其他任何 函数 完全一样。 Vue 的模板与 Javascript 的单独作用域相互作用，因此您必须将该静态数据写到 Vue 组件中，并将其作为计算属性字段返回。 这些东西都不是特别痛苦，但都是不必要的。

Virtual DOM 是一个轻量级的 JavaScript 对象，它最初只是 real DOM 的副本。它是一个节点树，它将元素、它们的属性和内容作为对象及其属性。 React 的渲染函数从 React 组件中创建一个节点树。然后它响应数据模型中的变化来更新该树，该变化是由用户或系统完成的各种动作引起的。

Virtual DOM 工作过程有三个简单的步骤。

1、每当底层数据发生改变时，整个 UI 都将在 Virtual DOM 描述中重新渲染。

2、然后计算之前 DOM 表示与新表示的之间的差异。

3、完成计算后，将只用实际更改的内容更新 real DOM。

二、为什么浏览器无法读取JSX？

浏览器只能处理 JavaScript 对象，而不能读取常规 JavaScript 对象中的 JSX。所以为了使浏览器能够读取 JSX，首先，需要用像 Babel 这样的 JSX 转换器将 JSX 文件转换为 JavaScript 对象，然后再将其传给浏览器。

每个React组件强制要求必须有一个 render() 。它返回一个 React 元素，是原生 DOM 组件的表示。如果需要渲染多个 HTML 元素，则必须将它们组合在一个封闭标记内，例如 <form> 、 <group> 、 <div> 等。此函数必须保持纯净，即必须每次调用时都返回相同的结果。

componentWillMount() – 在渲染之前执行，在客户端和服务器端都会执行。

componentDidMount() – 仅在第一次渲染后在客户端执行。

componentWillReceiveProps() – 当从父类接收到 props 并且在调用另一个渲染器之前调用。

shouldComponentUpdate() – 根据特定条件返回 true 或 false。如果你希望更新组件，请返回 true 否则返回 false 。默认情况下，它返回 false。

componentWillUpdate() – 在 DOM 中进行渲染之前调用。

componentDidUpdate() – 在渲染发生后立即调用。

componentWillUnmount() – 从 DOM 卸载组件后调用。用于清理内存空间。

Refs 是 React 中引用的简写。它是一个有助于存储对特定的 React 元素或组件的引用的属性，它将由组件渲染配置函数返回。用于对 render() 返回的特定元素或组件的引用。当需要进行 DOM 测量或向组件添加方法时，它们会派上用场。

React 会创建一个虚拟 DOM(virtual DOM)。当一个组件中的状态改变时，React 首先会通过 "diffing" 算法来标记虚拟 DOM 中的改变，第二步是调节(reconciliation)，会用 diff 的结果来更新 DOM。

高阶组件是重用组件逻辑的高级方法，是一种源于 React 的组件模式。 HOC 是自定义组件，在它之内包含另一个组件。它们可以接受子组件提供的任何动态，但不会修改或复制其输入组件中的任何行为。你可以认为 HOC 是“纯（Pure）”组件。

HOC可用于许多任务，例如：

Redux 使用 “Store” 将程序的整个状态存储在同一个地方。因此所有组件的状态都存储在 Store 中，并且它们从 Store 本身接收更新。单一状态树可以更容易地跟踪随时间的变化，并调试或检查程序。

因为 thisprops 和 thisstate 的更新可能是异步的，不能依赖它们的值去计算下一个 state。

本文主要介绍 UmiJS 的预渲染功能。

服务端渲染（Server-Side Rendering），是指由 服务端 完成页面的 HTML 结构拼接的页面处理技术，发送到浏览器，然后为其绑定状态与事件，成为完全可交互页面的过程。

服务端渲染，首先得有后端服务器（一般是 Nodejs）才可以使用，而没有后端服务器的情况下，可以使用 预渲染 。

预渲染与服务端渲染唯一的不同点在于 渲染时机 ，服务端渲染的时机是在用户访问时执行渲染（即实时渲染，数据一般是最新的），预渲染的时机是在项目构建时，当用户访问时，数据不一定是最新的（ 如果数据没有实时性，可以直接考虑预渲染 ）。

预渲染在构建时执行渲染，将渲染后的 HTML 片段生成静态 HTML 文件。无需使用 web 服务器实时动态编译 HTML，适用于 静态站点生成 。

Umi3 在 SSR 上做了大量优化及开发体验的提升，具有以下特性：

默认情况下，服务端渲染时关闭的，可通过配置开启：

服务端渲染的数据获取方式与 SPA(单页应用) 有所不同，为了让客户端和服务端都能获取到同一份数据，Umi 提供了页面级数据的预获取。

每个页面可能有单独的数据预获取逻辑，这里我们会获取页面组件上的 getInitialProps 静态方法，执行后将结果注入到该页面组件的 props 中，如：

getInitialProps 有几个固定参数：

为了结合数据流框架，我们提供了 modifyGetInitialPropsCtx 方法，由插件或应用来扩展 ctx 参数，以 dva 为例：

然后在页面中，可以获取到 store ：

同时也可以在自身应用中进行扩展：

同时可以使用 getInitialPropsCtx 将服务端参数扩展到 ctx 中，例如：

在使用的时候，就有 req 对象，不过需要注意的是，只在服务端执行时才有此参数：

则在执行 getInitialProps 方法时，除了以上两个固定参数外，还会获取到 title 和 store 参数。

关于 getInitialProps 执行逻辑和时机，需要注意：

执行 umi build ，除了正常的 umijs 外，会多一个服务端文件： umiserverjs （相当于服务端入口文件）。然后在后端框架中，引用该文件：

render 方法参数和返回值如下：

完美兼容客户端动态加载，配置如下：

@umijs/preset-react 插件集中已内置对标题的渲染，通过以下步骤使用：

@umijs/preset-react 插件集中已内置 dva

这时候 getInitialProps(ctx) 中的 ctx 就会有 store 属性，可执行 dispatch ，并返回初始化数据。

Umi 同时支持对服务端和客户端包大小的分析