React18发布Vue3VitestPinia正式成为Vu

　　Vue3、Vitest中文文档上线Pinia正式成为Vue官方默认推荐的状态管理库Vitev2。9。0React18发布ReactRouterv6。3。0FEHunter前端赏金猎人CasePolicefreeprogrammingbookszhCN100coolwebmoments技术资讯Vue3、Vitest中文文档均已上线Vue中文文档地址Vitest中文文档地址Pinia正式成为Vue官方默认推荐的状态管理库
　　Pinia终于转正了，它具有与Vuex5几乎完全相同或者增强的API，简单来说，它就是和Vuex5名字不同。Vuex3和4仍会继续维护，但是新功能不太可能会添加了。Pinia也支持渐进式迁移，Vuex和Pinia可以安装在同一个项目中，新项目的话建议直接使用Pinia。Vitev2。9。0
　　Vite发布了v2。9。0。更快地冷启动；开发期间的CSSSourcemap支持（实验性）；WebWorker增强功能；给插件和框架作者提供的新API。React18发布
　　React18终于发布了，官方团队从v16就开始普及并发概念，到正式版发布时难免少了一些新鲜感。照目前的发展趋势看，React未来会朝着前端底层操作系统的方向发展，会变得越来越复杂。这些复杂的操作又会被元框架（Next。js、Remix）消化掉，开发者并不会直接接触，使用这些元框架开发即可。ReactRouterv6。3。0
　　稳定不停滞，支持增量升级，v5、v6的版本代码可以同时存在。
　　下面是其他的发布信息和TC39提案的一些推进情况，大家可以找感兴趣的自行查阅。其他发布reactthreefiberv8Valtiov1。5。0Webpackv5。71。0Electronv18。0。0pnpmv7。0。0rc。1ReactNativev0。68ReactTestingLibraryv13VSCodeMarch2022TypeAnnotationstoStage1ChangeArraybycopytostage3Decoratorstostage3
　　下面我们来看技术资料。技术资料FEHunter
　　和好朋友卡颂一起在做的项目：前端赏金猎人。
　　这是一个用单纯的金钱关系维系的前端学习社区，悬赏答题答题赚钱。
　　期待你的加入，如果觉得有价值的话，可以给个Star鼓励一下。CasePolice
　　把技术名词的大小写拼写正确是基本的素养，但很多人都不重视，这个项目可以帮助你纠正错误的大小写。freeprogrammingbookszhCN
　　免费的编程中文书籍索引，项目已有90。1kStar。100coolwebmoments
　　从2008年谷歌浏览器推出至今的100个精彩瞬间回忆录。Pinia与Vuex的对比
　　在这里插入图片描述介绍
　　Pinia是Vue。js的轻量级状态管理库，最近很受欢迎。它使用Vue3中的新反应系统来构建一个直观且完全类型化的状态管理库。
　　Pinia的成功可以归功于其管理存储数据的独特功能（可扩展性、存储模块组织、状态变化分组、多存储创建等）。
　　另一方面，Vuex也是为Vue框架建立的一个流行的状态管理库，它也是Vue核心团队推荐的状态管理库。Vuex高度关注应用程序的可扩展性、开发人员的工效和信心。它基于与Redux相同的流量架构。
　　在这篇文章中，我们将对Pinia和Vuex进行比较。我们将分析这两个框架的设置、社区优势和性能。我们还将看一下Vuex5与Pinea2相比的新变化。设置
　　Pinia设置
　　Pinia很容易上手，因为它只需要安装和创建一个store。
　　要安装Pinia，您可以在终端中运行以下命令：yarnaddpinianextorwithnpmnpminstallpinianext
　　该版本与Vue3兼容，如果你正在寻找与Vue2。x兼容的版本，请查看v1分支。
　　Pinia是一个围绕Vue3CompositionAPI的封装器。因此，你不必把它作为一个插件来初始化，除非你需要Vuedevtools支持、SSR支持和webpack代码分割的情况：app。jsimport｛createPinia｝frompiniaapp。use（createPinia（））
　　在上面的片段中，你将Pinia添加到Vue。js项目中，这样你就可以在你的代码中使用Pinia的全局对象。
　　为了创建一个store，你用一个包含创建一个基本store所需的states、actions和getters的对象来调用defineStore方法。storestodo。jsimport｛defineStore｝frompiniaexportconstuseTodoStoredefineStore（｛id：todo，state：（）（｛count：0，title：Cooknoodles，done：false｝）｝）Vuex设置
　　Vuex也很容易设置，需要安装和创建store。
　　要安装Vuex，您可以在终端中执行以下命令：npminstallvuexnextsaveorwithyarnyarnaddvuexnextsave
　　要创建store，你可以使用包含创建基本store所需的states、actions和getter的对象调用createStore方法：store。jsimport｛createStore｝fromvuexconstuseStorecreateStore（｛state：｛todos：〔｛id：1，title：。。。，done：true｝〕｝，getters：｛doneTodos（state）｛returnstate。todos。filter（todotodo。done）｝｝｝）
　　要访问Vuex全局对象，需要在Vue。js项目根文件中添加Vuex，如下所示：index。jsimport｛createApp｝fromvueimportAppfrom。App。vueimport｛useStore｝from。storecreateApp（App）。use（store）。mount（app）使用Pinia使用
　　使用Pinia，可以按如下方式访问该store：exportdefaultdefineComponent（｛setup（）｛consttodouseTodoStore（）return｛只允许访问特定的statestate：computed（（）todo。title），｝｝，｝）
　　请注意，在访问其属性时省略了store的state对象。Vuex使用
　　使用Vuex，可以按如下方式访问store：import｛computed｝fromvueexportdefault｛setup（）｛conststoreuseStore（）return｛访问计算函数中的状态count：computed（（）store。state。count），访问计算函数中的getterdouble：computed（（）store。getters。double）｝｝｝学习曲线和文档
　　这两个状态管理库都相当容易学习，因为它们在YouTube和第三方博客上都有很好的文档和学习资源。对于以前有使用Redux、MobX、Recoil等Flux架构库经验的开发人员来说，他们的学习曲线更容易。
　　这两个库的文档都很棒，并且以对经验丰富的开发人员和新开发人员都友好的方式编写。性能
　　Pinia和Vuex都非常快，在某些情况下，使用Pinia的web应用程序会比使用Vuex更快。这种性能的提升可以归因于Pinia的极轻的重量，Pinia体积约1KB。
　　尽管Pinia是在Vuedevtools的支持下建立的，但由于Vuedevtools没有暴露出必要的API，所以一些功能如时间旅行和编辑仍然不被支持。当开发速度和调试对你的项目来说更重要时，这是值得注意的。比较Pinia2和Vuex4
　　Pinia将这些与Vuex3和4进行了比较：突变不再存在。他们经常被认为非常冗长。他们最初带来了devtools集成，但这不再是问题。无需创建自定义的复杂包装器来支持TypeScript，所有内容都是类型化的，并且API的设计方式尽可能地利用TS类型推断。
　　这些是Pinia在其状态管理库和Vuex之间的比较中提出的额外见解：Pinia不支持嵌套存储。相反，它允许你根据需要创建store。但是，store仍然可以通过在另一个store中导入和使用store来隐式嵌套存储器在被定义的时候会自动被命名。因此，不需要对模块进行明确的命名。Pinia允许你建立多个store，让你的捆绑器代码自动分割它们Pinia允许在其他getter中使用getterPinia允许使用patch在devtools的时间轴上对修改进行分组。this。patch（（state）｛state。posts。push（post）state。user。postsCount｝）。catch（error）｛this。errors。push（error）｝
　　将Pinia2（目前处于alpha阶段）与Vuex进行比较，我们可以推断出Pinia领先于Vuex4。
　　Vue。js核心团队为Vuex5制定了一个开放的RFC，类似于Pinia使用的RFC。目前，Vuex通过RFC来尽可能多地收集社区的反馈。希望Vuex5的稳定版本能够超越Pinea2。
　　据同时也是Vue。js核心团队成员并积极参与Vuex设计的Pinia的创建者（EduardoSanMartinMorote）所说，Pania和Vuex的相似之处多于不同之处：
　　Pinia试图尽可能地接近Vuex的理念。它的设计是为了测试Vuex的下一次迭代的建议，它是成功的，因为我们目前有一个开放的RFC，用于Vuex5，其API与Pinea使用的非常相似。我对这个项目的个人意图是重新设计使用全局Store的体验，同时保持Vue的平易近人的理念。我保持Pinea的API与Vuex一样接近，因为它不断向前发展，使人们很容易迁移到Vuex，甚至在未来融合两个项目（在Vuex下）。
　　尽管Pinia足以取代Vuex，但取代Vuex并不是它的目标，因此Vuex仍然是Vue。js应用程序的推荐状态管理库。Vuex和Pinia的优缺点Vuex的优点支持调试功能，如时间旅行和编辑适用于大型、高复杂度的Vue。js项目Vuex的缺点从Vue3开始，getter的结果不会像计算属性那样缓存Vuex4有一些与类型安全相关的问题Pinia的优点完整的TypeScript支持：与在Vuex中添加TypeScript相比，添加TypeScript更容易极其轻巧（体积约1KB）store的action被调度为常规的函数调用，而不是使用dispatch方法或MapAction辅助函数，这在Vuex中很常见支持多个Store支持Vuedevtools、SSR和webpack代码拆分Pinia的缺点不支持时间旅行和编辑等调试功能何时使用Pinia，何时使用Vuex
　　根据我的个人经验，由于Pinea是轻量级的，体积很小，它适合于中小型应用。它也适用于低复杂度的Vue。js项目，因为一些调试功能，如时间旅行和编辑仍然不被支持。
　　将Vuex用于中小型Vue。js项目是过度的，因为它重量级的，对性能降低有很大影响。因此，Vuex适用于大规模、高复杂度的Vue。js项目。
　　React18的几个新功能
　　1、自动批处理以减少渲染什么是批处理？
　　批处理是React将多个状态更新分组到单个重新渲染中以获得更好的性能。
　　例如，如果你在同一个点击事件中有两个状态更新，React总是将它们分批处理到一个重新渲染中。如果你运行下面的代码，你会看到每次点击时，React只执行一次渲染，尽管你设置了两次状态：functionApp（）｛const〔count，setCount〕useState（0）；const〔flag，setFlag〕useState（false）；functionhandleClick（）｛setCount（cc1）；还没有重新渲染setFlag（f！f）；还没有重新渲染React只会在最后重新渲染一次（这是批处理！）｝return（pbuttononClick｛handleClick｝Nextbuttonh1style｛｛color：flag？blue：black｝｝｛count｝h1p）；｝
　　这对性能非常有用，因为它避免了不必要的重新渲染。它还可以防止你的组件呈现仅更新一个状态变量的半完成状态，这可能会导致错误。
　　这可能会让你想起餐厅服务员在你选择第一道菜时不会跑到厨房，而是等你完成订单。
　　然而，React的批量更新时间并不一致。例如，如果你需要获取数据，然后更新handleClick上面的状态，那么React不会批量更新，而是执行两次独立的更新。
　　这是因为React过去只在浏览器事件（如点击）期间批量更新，但这里我们在事件已经被处理（在fetch回调中）之后更新状态：functionApp（）｛const〔count，setCount〕useState（0）；const〔flag，setFlag〕useState（false）；functionhandleClick（）｛fetchSomething（）。then（（）｛React17及更早版本不会对这些进行批处理，因为它们在回调中after事件运行，而不是during它setCount（cc1）；导致重新渲染setFlag（f！f）；导致重新渲染｝）；｝return（buttononClick｛handleClick｝Nextbuttonh1style｛｛color：flag？blue：black｝｝｛count｝h1）；｝
　　在React18之前，我们只在React事件处理程序期间批量更新。默认情况下，React中不会对promise、setTimeout、本机事件处理程序或任何其他事件中的更新进行批处理。什么是自动批处理？
　　从React18开始createRoot，所有更新都将自动批处理，无论它们来自何处。
　　这意味着超时、承诺、本机事件处理程序或任何其他事件内的更新将以与React事件内的更新相同的方式进行批处理。
　　我们希望这会导致更少的渲染工作，从而在你的应用程序中获得更好的性能：functionApp（）｛const〔count，setCount〕useState（0）；const〔flag，setFlag〕useState（false）；functionhandleClick（）｛fetchSomething（）。then（（）｛React18及更高版本确实批处理这些：setCount（cc1）；setFlag（f！f）；React只会在最后重新渲染一次（这是批处理！）｝）；｝return（buttononClick｛handleClick｝Nextbuttonh1style｛｛color：flag？blue：black｝｝｛count｝h1）；｝
　　注意：作为采用React18的一部分，预计你将升级到createRoot。旧行为的render存在只是为了更容易地对两个版本进行生产实验。
　　无论更新发生在何处，React都会自动批量更新，因此：functionhandleClick（）｛setCount（cc1）；setFlag（f！f）；Reactwillonlyrerenderonceattheend（thatsbatching！）｝行为与此相同：setTimeout（（）｛setCount（cc1）；setFlag（f！f）；Reactwillonlyrerenderonceattheend（thatsbatching！）｝，1000）；行为与此相同：fetch（。。。）。then（（）｛setCount（cc1）；setFlag（f！f）；Reactwillonlyrerenderonceattheend（thatsbatching！）｝）
　　行为与此相同：elm。addEventListener（click，（）｛setCount（cc1）；setFlag（f！f）；Reactwillonlyrerenderonceattheend（thatsbatching！）｝）；注意：React仅在通常安全的情况下才批量更新。例如，React确保对于每个用户启动的事件（如单击或按键），DOM在下一个事件之前完全更新。例如，这可确保在提交时禁用的表单不能被提交两次。如果我不想批处理怎么办？
　　通常，批处理是安全的，但某些代码可能依赖于在状态更改后立即从DOM中读取某些内容。对于这些用例，你可以使用ReactDOM。flushSync（）选择退出批处理：import｛flushSync｝fromreactdom；Note：reactdom，notreactfunctionhandleClick（）｛flushSync（（）｛setCounter（cc1）；｝）；ReacthasupdatedtheDOMbynowflushSync（（）｛setFlag（f！f）；｝）；ReacthasupdatedtheDOMbynow｝import｛flushSync｝fromreactdom；Note：reactdom，notreact
　　2、Suspense的SSR支持
　　这基本上是服务器端渲染（SSR）逻辑的扩展。在典型的ReactSSR应用程序中，会发生以下步骤：服务器获取需要在UI上显示的相关数据服务器将整个应用程序呈现为HTML并将其发送给客户端作为响应客户端下载JavaScript包（除了HTML）在最后一步，客户端将javascript逻辑连接到HTML（称为hydration）
　　典型SSR应用程序的问题在于，在下一步可以开始之前，必须立即完成整个应用程序的每个步骤。这会使您的应用程序在初始加载时变慢且无响应。
　　React18正试图解决这个问题。组件已经以这样的方式进行了革命性的改变，它将应用程序分解为更小的独立单元，这些单元经过提到的每个步骤。这样一旦用户看到内容，它就会变成互动的。3、startTransition什么是过渡？
　　我们将状态更新分为两类：紧急更新反映直接交互，如打字、悬停、拖动等。过渡更新将UI从一个视图过渡到另一个视图。
　　单击、悬停、滚动或打字等紧急更新需要立即响应以匹配我们对物理对象行为方式的直觉。否则他们会觉得错了。
　　然而，转换是不同的，因为用户不希望在屏幕上看到每个中间值。
　　例如，当您在下拉列表中选择过滤器时，您希望过滤器按钮本身在您单击时立即响应。但是，实际结果可能会单独转换。
　　一个小的延迟是难以察觉的，而且通常是预料之中的。如果在结果渲染完成之前再次更改过滤器，您只关心看到最新的结果。
　　在典型的React应用程序中，大多数更新在概念上都是过渡更新。但出于向后兼容性的原因，过渡是可选的。
　　默认情况下，React18仍然将更新处理为紧急更新，您可以通过将更新包装到startTransition。这解决了什么问题？
　　构建流畅且响应迅速的应用程序并不总是那么容易。有时，诸如单击按钮或输入输入之类的小动作可能会导致屏幕上发生很多事情。这可能会导致页面在所有工作完成时冻结或挂起。
　　例如，考虑在过滤数据列表的输入字段中键入。您需要将字段的值存储在state中，以便您可以过滤数据并控制该输入字段的值。您的代码可能如下所示：setSearchQuery（input）；
　　在这里，每当用户键入一个字符时，我们都会更新输入值并使用新值来搜索列表并显示结果。
　　对于大屏幕更新，这可能会导致页面在呈现所有内容时出现延迟，从而使打字或其他交互感觉缓慢且无响应。
　　即使列表不是太长，列表项本身也可能很复杂并且每次击键时都不同，并且可能没有明确的方法来优化它们的呈现。
　　从概念上讲，问题在于需要进行两种不同的更新。第一个更新是紧急更新，用于更改输入字段的值，以及可能会更改其周围的一些UI。
　　第二个是显示搜索结果的不太紧急的更新。紧急：显示输入的内容setInputValue（input）；不急：显示结果setSearchQuery（input）；
　　用户希望第一次更新是即时的，因为这些交互的本机浏览器处理速度很快。但是第二次更新可能会有点延迟。
　　用户不希望它立即完成，这很好，因为可能有很多工作要做。（实际上，开发人员经常使用去抖动等技术人为地延迟此类更新。）
　　在React18之前，所有更新都被紧急渲染。
　　这意味着上面的两个状态仍然会同时呈现，并且仍然会阻止用户看到他们交互的反馈，直到一切都呈现出来。我们缺少的是一种告诉React哪些更新是紧急的，哪些不是的方法。
　　新startTransitionAPI通过让您能够将更新标记为转换来解决此问题：
　　包装在其中的更新startTransition被视为非紧急处理，如果出现更紧急的更新（如点击或按键），则会中断。
　　如果用户中断转换（例如，连续输入多个字符），React将抛出未完成的陈旧渲染工作，仅渲染最新更新。
　　Transitions可让您保持大多数交互敏捷，即使它们导致显着的UI更改。它们还可以让您避免浪费时间渲染不再相关的内容。它与setTimeout有何不同？
　　上述问题的一个常见解决方案是将第二次更新包装在setTimeout中：import｛startTransition｝fromreact；紧急：显示输入的内容setInputValue（input）；将内部的任何状态更新标记为转换startTransition（（）｛Transition：显示结果setSearchQuery（input）；｝）；
　　这将延迟第二次更新，直到呈现第一次更新之后。节流和去抖动是这种技术的常见变体。
　　一个重要的区别是startTransition不安排在以后喜欢的setTimeout是。它立即执行。传递给的函数startTransition同步运行，但其中的任何更新都标记为转换。
　　React将在稍后处理更新时使用此信息来决定如何呈现更新。这意味着我们比在超时中包装更新更早地开始呈现更新。
　　在快速设备上，两次更新之间的延迟非常小。在较慢的设备上，延迟会更大，但UI会保持响应。
　　另一个重要的区别是a内的大屏幕更新setTimeout仍然会锁定页面，只是在超时之后。
　　如果用户在超时触发时仍在键入或与页面交互，他们仍将被阻止与页面交互。但是标记为的状态更新startTransition是可中断的，因此它们不会锁定页面。
　　它们让浏览器在呈现不同组件之间的小间隙中处理事件。
　　如果用户输入发生变化，React将不必继续渲染用户不再感兴趣的内容。
　　最后，因为setTimeout只是延迟更新，显示加载指示器需要编写异步代码，这通常很脆弱。
　　通过转换，React可以为您跟踪挂起状态，根据转换的当前状态更新它，并让您能够在用户等待时显示加载反馈。我可以在哪里使用它？
　　您可以使用startTransition来包装要移动到后台的任何更新。通常，这些类型的更新分为两类：缓慢渲染：这些更新需要时间，因为React需要执行大量工作才能转换UI以显示结果。慢速网络：这些更新需要时间，因为React正在等待来自网络的一些数据。此用例与Suspense紧密集成。
　　总结
　　React18没有任何重大更改，因此，我们将当前的存储库升级到最新版本几乎不需要更改代码，但我们可以享受它们很酷的功能。