vue项目部署iis服务器

一、将vue项目进行打包编译后，根目录生成dist的文件

当出现如上图显示时，说明打包编译完成，已经生成dist文件

二、打开iis服务器
打开iis服务器后选中网站后右击选添加网站，就可对网站进行配置，物理路径选择编译后的dist文件夹后选确定就行。

三、右击选择启动后出现如下报错信息：
除非Windows Activation Service (WAS)和万维网发布服务(W3SVC)均处于运行状态，否则无法启动网站

解决：
打开命令提示符中输入servicesmsc ,打开服务。
找到windows install及word wide web发布服务选项，分别右击启动，并右键属性改为启动类型就可以。

这是重新启动下，就可以访问。

The outside mail server is maintaining, please have the colleaguewhich the need sends the outside mail, temporarily uses own thirdparty outside mail (for example @163com) to transmit
After the abcdefgcom mail restores OK, I inform the first timeeverybody

vue3使用环境：Vue CLI 4x以上，Nodejs版本 89以上。

mainjs

Vite 是一个 web 开发构建工具，由于其原生 ES 模块导入方式，可以实现闪电般的冷服务器启动。使用 Vite 可以快速构建 Vue 项目。
Vite 需要 Nodejs版本 120以上。

在Vue3中，定义计算属性，需要引入computed组合式API。computed()函数的参数是一个回调函数，回调函数的返回值，就是计算属性的返回值。

在Vue3中，定义侦听器，需要引入 watch组合式API 。
watch函数 有三个参数：① 侦听谁，② 回调函数，③ 配置对象(可以省略)。如果监听的是一个对象/对象里的某个属性，第一个参数就是一个函数，由该函数返回指定对象中监视的属性。
注意： watch监视对象，默认开始深度监视，并且无法关闭。所以直接监视整个对象不好。vue3建议我们，监视对象时，指定监视对象的属性。如果监视的对象属性也是一个对象，默认不开启深度监视，需要手动开启。

watchEffect()监视器： 只有一个回调函数参数，并且没有参数。特点：① 该回调函数一开始会执行一次；② 不需要明确的去监视谁，回调函数里面用到了谁，谁变了，就会重新执行回调函数。

在Vue2中可以定义过滤器，但是在Vue3中已经取消了过滤器。Vue3推荐我们使用方法 或 计算属性的方式，实现之前过滤器的效果。

在vue3的模板中，不再需要根标签，它内部有一个fragment的组件作为模板的根标签。

有可能起冲突，但是经过简单的设置之后就可以避免，主要是两个DHCP服务器自动分派IP地址的地址段要错开，比如分别设置IP地址段为192168110～192168199 、1921681100～1921681200 。
另外，新创建的DHCP服务器的IP地址不能与路由器IP相同。

步骤：
一、找到文件vueconfigjs，没有则自己创建一个

二、编写vueconfigjs的内容

三、修改路由方式，修改为hash，文件位置自己找，vuecli3中在routerts文件中

四、添加空路由

找到编译好的文件夹，如果作为独立项目，直接拷贝后放到Tomcat里即可，如果是放到另外一个项目中使用，则拷贝到其它项目中去

七、适配到EOS中使用
71、改变原EOS项目中的首页配置
在webapps\default\WEB-INF\webxml中配置

72、修改原EOS项目中的登录成功的跳转页，也是项目主页
在webapps\default\coframe\auth\indexjsp中配置

之前一直是使用 webpack 构建项目， 但是那种随着项目越来越大 运行、打包、热更新缓慢 带来的无奈。。。

新项目开发果断使用了 vite20 , 和 webpack 对比起来， 其他的优点不是很直观，但在 运行、打包、热更新 方面简直倍数差距， 只能说我觉得 vite20 很舒服。

当然 vite 作为热门构建共建优点还是很多的，详情可以去官网看看 vite 官网地址

之前使用 webpack 构建项目一直使用动态导入 requirecontext API 自动化注册组件及路由；

转移到 vite 之后，开发习惯当然不能变；随即使用的是 importmetaglobEager 完成动态导入；

本地开发过程中很舒服没问题，打包后部署到服务器报错找不到动态导入的文件；裂开~~~

经过这几天陆陆续续的尝试最终解决，总结了以下几种方案

主要项目结构

文件内部

组件内部通过定义

vite 动态导入有两种方式

以下方案有需要自行取舍

使用 importmetaglob

缺点：

但是你可以用单独文件夹来区分，我认为限制性太大不够优雅；

使用 routerts

使用 importmetaglob 和 importmetaglobEager

使用 routerts （路由注册）

使用 maints （组件注册）

使用 importmetaglob 的 then 方法， 加上路由内置 addRoute（） 方法注册
缺点：

使用 routerts

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

---