你使用过 Vuex 吗&＃xff1f;
Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。每一个 Vuex 应用的核心就是 store&＃xff08;仓库&＃xff09;。“store” 基本上就是一个容器&＃xff0c;它包含着你的应用中大部分的状态 ( state )。
&＃xff08;1&＃xff09;Vuex 的状态存储是响应式的。当 Vue 组件从 store 中读取状态的时候&＃xff0c;若 store 中的状态发生变化&＃xff0c;那么相应的组件也会相应地得到高效更新。
&＃xff08;2&＃xff09;改变 store 中的状态的唯一途径就是显式地提交 (commit) mutation。这样使得我们可以方便地跟踪每一个状态的变化。
主要包括以下几个模块&＃xff1a;
- State&＃xff1a;定义了应用状态的数据结构&＃xff0c;可以在这里设置默认的初始状态。
- Getter&＃xff1a;允许组件从 Store 中获取数据&＃xff0c;mapGetters 辅助函数仅仅是将 store 中的 getter 映射到局部计算属性。
- Mutation&＃xff1a;是唯一更改 store 中状态的方法&＃xff0c;且必须是同步函数。
- Action&＃xff1a;用于提交 mutation&＃xff0c;而不是直接变更状态&＃xff0c;可以包含任意异步操作。
- Module&＃xff1a;允许将单一的 Store 拆分为多个 store 且同时保存在单一的状态树中。
17、使用过 Vue SSR 吗&＃xff1f;说说 SSR&＃xff1f;
Vue.js 是构建客户端应用程序的框架。默认情况下&＃xff0c;可以在浏览器中输出 Vue 组件&＃xff0c;进行生成 DOM 和操作 DOM。然而&＃xff0c;也可以将同一个组件渲染为服务端的 HTML 字符串&＃xff0c;将它们直接发送到浏览器&＃xff0c;最后将这些静态标记"激活"为客户端上完全可交互的应用程序。
即&＃xff1a;SSR大致的意思就是vue在客户端将标签渲染成的整个 html 片段的工作在服务端完成&＃xff0c;服务端形成的html 片段直接返回给客户端这个过程就叫做服务端渲染。
服务端渲染 SSR 的优缺点如下&＃xff1a;
&＃xff08;1&＃xff09;服务端渲染的优点&＃xff1a;
- 更好的 SEO&＃xff1a; 因为 SPA 页面的内容是通过 Ajax 获取&＃xff0c;而搜索引擎爬取工具并不会等待 Ajax 异步完成后再抓取页面内容&＃xff0c;所以在 SPA 中是抓取不到页面通过 Ajax 获取到的内容&＃xff1b;而 SSR 是直接由服务端返回已经渲染好的页面&＃xff08;数据已经包含在页面中&＃xff09;&＃xff0c;所以搜索引擎爬取工具可以抓取渲染好的页面&＃xff1b;
- 更快的内容到达时间&＃xff08;首屏加载更快&＃xff09;&＃xff1a; SPA 会等待所有 Vue 编译后的 js 文件都下载完成后&＃xff0c;才开始进行页面的渲染&＃xff0c;文件下载等需要一定的时间等&＃xff0c;所以首屏渲染需要一定的时间&＃xff1b;SSR 直接由服务端渲染好页面直接返回显示&＃xff0c;无需等待下载 js 文件及再去渲染等&＃xff0c;所以 SSR 有更快的内容到达时间&＃xff1b;
&＃xff08;2) 服务端渲染的缺点&＃xff1a;
- 更多的开发条件限制&＃xff1a; 例如服务端渲染只支持 beforCreate 和 created 两个钩子函数&＃xff0c;这会导致一些外部扩展库需要特殊处理&＃xff0c;才能在服务端渲染应用程序中运行&＃xff1b;并且与可以部署在任何静态文件服务器上的完全静态单页面应用程序 SPA 不同&＃xff0c;服务端渲染应用程序&＃xff0c;需要处于 Node.js server 运行环境&＃xff1b;
- 更多的服务器负载&＃xff1a;在 Node.js 中渲染完整的应用程序&＃xff0c;显然会比仅仅提供静态文件的 server 更加大量占用CPU 资源 (CPU-intensive - CPU 密集)&＃xff0c;因此如果你预料在高流量环境 ( high traffic ) 下使用&＃xff0c;请准备相应的服务器负载&＃xff0c;并明智地采用缓存策略。
如果没有 SSR 开发经验的同学&＃xff0c;可以参考本文作者的另一篇 SSR 的实践文章《Vue SSR 踩坑之旅》&＃xff0c;里面 SSR 项目搭建以及附有项目源码。
vue-router 路由模式有几种&＃xff1f;
vue-router 有 3 种路由模式&＃xff1a;hash、history、abstract&＃xff0c;对应的源码如下所示&＃xff1a;
switch (mode) {case &＃39;history&＃39;:this.history &＃61; new HTML5History(this, options.base)breakcase &＃39;hash&＃39;:this.history &＃61; new HashHistory(this, options.base, this.fallback)breakcase &＃39;abstract&＃39;:this.history &＃61; new AbstractHistory(this, options.base)breakdefault:if (process.env.NODE_ENV !&＃61;&＃61; &＃39;production&＃39;) {assert(false, &＃96;invalid mode: ${mode}&＃96;)}
}
其中&＃xff0c;3 种路由模式的说明如下&＃xff1a;
hash: 使用 URL hash 值来作路由。支持所有浏览器&＃xff0c;包括不支持 HTML5 History Api 的浏览器&＃xff1b;
history : 依赖 HTML5 History API 和服务器配置。具体可以查看 HTML5 History 模式&＃xff1b;
abstract : 支持所有 Javascript 运行环境&＃xff0c;如 Node.js 服务器端。如果发现没有浏览器的 API&＃xff0c;路由会自动强制进入这个模式.
19、能说下 vue-router 中常用的 hash 和 history 路由模式实现原理吗&＃xff1f;
&＃xff08;1&＃xff09;hash 模式的实现原理
早期的前端路由的实现就是基于 location.hash 来实现的。其实现原理很简单&＃xff0c;location.hash 的值就是 URL 中 # 后面的内容。比如下面这个网站&＃xff0c;它的 location.hash 的值为 &＃39;#search&＃39;&＃xff1a;
https://www.word.com#search
hash 路由模式的实现主要是基于下面几个特性&＃xff1a;
- URL 中 hash 值只是客户端的一种状态&＃xff0c;也就是说当向服务器端发出请求时&＃xff0c;hash 部分不会被发送&＃xff1b;
- hash 值的改变&＃xff0c;都会在浏览器的访问历史中增加一个记录。因此我们能通过浏览器的回退、前进按钮控制hash 的切换&＃xff1b;
- 可以通过 a 标签&＃xff0c;并设置 href 属性&＃xff0c;当用户点击这个标签后&＃xff0c;URL 的 hash 值会发生改变&＃xff1b;或者使用 Javascript 来对 loaction.hash 进行赋值&＃xff0c;改变 URL 的 hash 值&＃xff1b;
- 我们可以使用 hashchange 事件来监听 hash 值的变化&＃xff0c;从而对页面进行跳转&＃xff08;渲染&＃xff09;。
&＃xff08;2&＃xff09;history 模式的实现原理
HTML5 提供了 History API 来实现 URL 的变化。其中做最主要的 API 有以下两个&＃xff1a;history.pushState() 和 history.repalceState()。这两个 API 可以在不进行刷新的情况下&＃xff0c;操作浏览器的历史纪录。唯一不同的是&＃xff0c;前者是新增一个历史记录&＃xff0c;后者是直接替换当前的历史记录&＃xff0c;如下所示&＃xff1a;
window.history.pushState(null, null, path);
window.history.replaceState(null, null, path);
history 路由模式的实现主要基于存在下面几个特性&＃xff1a;
- pushState 和 repalceState 两个 API 来操作实现 URL 的变化 &＃xff1b;
- 我们可以使用 popstate 事件来监听 url 的变化&＃xff0c;从而对页面进行跳转&＃xff08;渲染&＃xff09;&＃xff1b;
- history.pushState() 或 history.replaceState() 不会触发 popstate 事件&＃xff0c;这时我们需要手动触发页面跳转&＃xff08;渲染&＃xff09;。
京公网安备 11010802041100号