由于之前的 vue 项目打包成果物一直是嵌入集成平台中,所以一直没有关注过项目的 title。直到最近,突然有个需求,要求点击按钮在集成平台外新开一个页面,此时我才发现,原来我的项目的 title 一直是万年不变的 vue-project。理所应当的,这个问题被测试爸爸提了一个大大的缺陷。
犯了错的我赶紧解决这个问题,但是经过一段时间的摸索,我却发现,这一个小小的问题,却有着很多不同的解法。
首先,毫无疑问的是,我们应该使用 document.title 方法通过 dom 操作来修改 title 的值。此时,距离解决问题还差两步:
ps:很多人提到过在微信或者一部分 IOS webview (下文一律以微信指代)中无法通过 document.title 方法修改 title 的值,这个问题的解决方案在文末的彩蛋中会提及。
接下来进入第一个重点:title 的传递。根据传递 title 值的方式,分为两种方案:
何为全局变量传递?全局变量传递指的是所有页面维护同一个全局变量,切换页面对其重新赋值,最常见的方法是使用 Vuex,当然,如果你要使用 this.$root 甚至丧心病狂地想要使用 provide/inject 一样可以达到类似的效果。
路由传递的方法就比较容易理解了,即通过路由跳转传参传递 title 的值。由于业务逻辑中本身就包含大量的路由传参,为了解耦方便后续维护,推荐将 title 的值通过路由配置中的 meta 进行传递。
之后,通过访问当前路由对象($route)的 meta 属性即可获取到 title 值。
// router.js
const routes = [
{
path: '/',
...
meta: {
title: '首页'
}
}, {
path: '/A',
meta: {
title: 'A模块'
}
}
]
// 业务模块,获取 title
...
beforeCreate () {
console.log(this.$route.meta)
}
...
通过上面的两种方法,可以顺利传递 title 的值。
完成了 title 值的传递,接下来我们谈谈何时该修改 title。
想到这个问题,大多数人第一个想到的应该就是在生命周期钩子中修改 title。
一般情况下,我们在 mounted 生命周期钩子中进行初始化请求,所以惯性思维之下,我在 mounted 中进行了 title 的修改。
// 业务代码
mounted () {
document.title = this.$route.meta.title
}
结果,效果不佳,标签页的 title 延迟 1 秒以上才成功修改。通过这个延迟可以发现,显然,我们的代码执行地太晚了!
回忆了一下 Vue 源码中初始化相关的代码细节,我们可以发现,我们甚至在 beforeCreate 钩子中就可以进行 title 的修改。
改动后的代码如下:
// 业务代码
beforeCreate () {
document.title = this.$route.meta.title
}
可以发现,修改后的代码效果明显好了许多,延迟感虽然还有,但是已经不太明显。
比起在生命周期钩子中修改 title 值,在路由跳转时利用路由守卫完成 title 的修改,岂不美哉?毕竟路由跳转发生在生命周期函数执行之前,使用路由守卫修改 title 值可以明显降低 title 修改的延时。
// router.js
router.beforeEach((to, from, next) => {
document.title = to.meta.title
next()
})
此时,我们基本完美完成了功能需求,但是,还是有一点小瑕疵——如果 meta 中没有定义 title 值,此时 title 值就变成了 undefined,扑街~
所以,我们需要设置默认的 title 值(一般可以是该项目的名称),作为 title 值不存在时的备胎。修改后的代码如下:
// router.js
const defaultTitle = '默认 title'
router.beforeEach((to, from, next) => {
document.title = to.meta.title ? to.meta.title : defaultTitle
next()
})
到这里为止,我们完美实现了需求,并且实现了该功能与业务代码的解耦。
vue-meta 插件在安装时,像 Vuex 类似,注入了全局状态——metaInfo,你可以通过定义 metaInfo 对象中的 title 属性,实现 title 的动态修改。
在搜索相关资料的时候,vue-wechat-title 这个包的出现频率出乎意料的高,这个包主要解决了前面提到的那个问题:在微信中无法通过 document.title 方法修改 title 的值。当然,这个兼容性问题都能解决了,正常情况下的 title 修改当然不在话下。
我们先来看看 vue-wechat-title 的源码:
// vue-wechat-title 源码
(function () {
// 插件安装钩子
function install (Vue) {
var setWechatTitle = function (title, img) {
if (title === undefined || window.document.title === title) {
return
}
// 修改 title
document.title = title
var mobile = navigator.userAgent.toLowerCase()
// 兼容性判断
if (/iphone|ipad|ipod/.test(mobile)) {
// 创建空的 iframe,触发 onload 事件
var iframe = document.createElement('iframe')
iframe.style.display = 'none'
// 替换成站标favicon路径或者任意存在的较小的图片即可
iframe.setAttribute('src', img || 'data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7')
// onload 回调函数
var iframeCallback = function () {
setTimeout(function () {
// 卸磨杀驴
iframe.removeEventListener('load', iframeCallback)
document.body.removeChild(iframe)
}, 0)
}
// 定义事件
iframe.addEventListener('load', iframeCallback)
document.body.appendChild(iframe)
}
}
// 定义全局指令,
Vue.directive('wechat-title', function (el, binding) {
// update 钩子,调用 title 修改函数
setWechatTitle(binding.value, el.getAttribute('img-set') || null)
})
}
if (typeof exports === 'object') {
module.exports = install
} else if (typeof define === 'function' && define.amd) {
define([], function () {
return install
})
} else if (window.Vue) {
Vue.use(install)
}
})()
由于微信浏览器只在onload 事件中通过 title 的值初始化标题,而后续的 title 修改,无法触发标题的修改。既然 onload 事件能够通过 title 修改标题,那么我创建一个空的 iframe 触发 onload 事件修改了标题后就移除它。这种方式根据 title 修改了标题,并且没有对页面造成额外的影响。
众所周知,vue-wechat-title 通过 v-wechat-title 指令来触发 title 的动态修改,每当指令的值修改后,触发 update 钩子中的回调函数——setWechatTitle。该函数通过前面提到的兼容性处理,实现了document.title 对标题的修改。
原文来自:https://www.cnblogs.com/karthuslorin/archive/2019/06/11/11000431.html
越来越多的人开始站队 Angular、Vue、React,仅仅围绕这些库或者框架进行前端技术讨论,这实在不是什么好的现象。其实我想基于我个人的经验聊下前端的演进和未来,希望可以贡献微薄的力量,消除一些我个人认为的前端社区不太好的风气。
近几年可谓是 JavaScript 的大爆炸纪元,各种框架类库层出不穷,它们给前端带来一个又一个的新思想。从以前我们用的 jQuery 直接操作 DOM,到 BackboneJS、Dojo 提供监听器的形式,在到 Ember.js、AngularJS 数据绑定的理念,再到现在的 React、Vue 虚拟 DOM 的思想。
新框架(新工具,语言),一、了解概念,把握思路,二、迅速实战,见招拆招,三、深入文档,求人不如求己,四、掌握原理,有恃无恐,五、源码分析,自立门户。如果你已经熟悉一门计算机语言,当再学习其他语言的时候,会发现他们几乎是大同小异,对比着学习,会令你事半功倍。
我曾见过很多很多人盲目地使用(前端)框架,如 React,Angular 或 Vue等等。这些框架提供了许多有意思的东西:它们支持组件化;它们有强大的社区支持;它们有很多(基于框架的)第三方库来解决问题;它们有很多(很好的)第三方组件;它们有浏览器扩展工具来帮助调试;它们适合做单页应用。
Web 技术变化得很快,而最佳技术实践也在不断发展。Uber 的 Web 平台团队开发了 Fusion.js,一个开源的 Web 框架,用于简化 Web 开发,并构建出高性能的轻量级 Web 应用程序。
要使用现代的前端框架,你需要下载开发环境和依赖,编译代码,然后在浏览器上运行。这个是好是坏?究竟是什么导致了这种不必要的复杂性?是因为我们构建的网站太复杂,还是因为框架本身就很复杂?
有一个流传较广的笑话,一个人在stackoverflow中提了一个问题,如何使用javascript实现一个数字与另外一个数字相加。最高票回答是你应该使用jQuery插件,jQuery插件可以做任何事情。 历史总是在重演,以前是jQuery,现在可能是react或vue。不同的框架有不同的应用场景,杀鸡不要用牛刀
Web框架(Web framework)是一种开发框架,用来支持动态网站、网络应用和网络服务的开发。这大多数的web框架提供了一套开发和部署网站的方式,也为web行为提供了一套通用的方法
Ionic 是一个高级的 HTML5 移动端应用框架,也是一个开发混合移动应用的前端框架,旨在让 Web 开发者更轻松地构建、测试、部署和监控跨平台应用。Ionic 基于 Angular 语法,之前一直不支持 Vue 和 React 。
最近想找一个简单的.Net下的轻量级Web框架,作为用户的本地的一个WebServer,实现同浏览器程序的一些简单交互,并调用本地服务,实现类似浏览器插件的功能。它有如下几点要求:
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!