// 正确的做法
.reveal { color: red; left: 10px; }
ele.className += ‘reveal’
ele.classList.add(‘reveal’)
3、将JS从HTML中抽离:从JS文件放入外置文件中
4、将HTML从JS中抽离:不要在innerHTML中拼接DOM结构,而是使用字符串模板,如handlerbars
简而言之,就是js里面就不要写样式了,用className 来控制,也不要拼接 html 了,用模版来实现
==================================================================
创建全局变量被认为是糟糕的实践,尤其在团队开发的大背景下更是问题多多。随着代码量的增长,全局变量会导致一些非常重要的可维护性难题,全局变量越多,引入错误的概率会变得越高
一般而言,有如下三种解决办法:
1、零全局变量
实现方法是使用一个立即调用函数IIFE并将所有脚本放置其中
(function() {
var doc = window.document
})(window)
这种模式的使用场景有限,只要代码需要被其他的代码所依赖,或者需要在运行中被不断扩展或修改,就不能使用这种方式
2、单全局变量和命名空间
依赖尽可能少的全局变量,即只创建一个全局变量,使用单变量模式,如YUI或jQuery。
单全局变量,即所创建的这个唯一全局对象名是独一无二的,并将所有的功能代码都挂载到这个全局对象上。因此,每个可能的全局变量,都成为唯一全局变量的属性,从而不会创建多个全局变量。
命名空间是简单的通过全局对象的单一属性表示的功能性分组。比如Y.DOM下的所有方法都是和DOM操作相关的,Y.Event下的所有方法都是和事件相关的。常见的约定是每个文件中都通过新的全局对象来声明自己的命名空间。
3、使用模块
模块是一种通用的功能片段,它并没有创建新的全局变量或命名空间。相反,所有的这些代码都存放于一个表示执行一个任务或发布一个接口的单函数中。可以用一个名称来表示这个模块,同样这个模块可以依赖其他模块
==================================================================
将事件处理相关的代码和事件环境耦合在一起,导致可维护性很糟糕
1、隔离应用逻辑
将应用逻辑从所有事件处理程序中抽离出来是一种最佳实践,将应用逻辑和事件处理的代码拆分开来
// 不好的做法
function handleClick(event) {
var popup = document.getElementById(‘popup’)
popup.style.left = event.clientX + ‘px’
popup.style.top = event.clientY = ‘px’
popup.className = ‘reveal’
}
addListener(element, ‘click’, handleClick)
// 好的做法
var MyApplication = {
handleClick: function(event) {
this.showPopup(event)
},
showPopup: function(event) {
var popup = document.getElementById(‘popup’)
popup.style.left = event.clientX + ‘px’
popup.style.top = event.clientY + ‘px’
popup.className = ‘reveal’
}
}
2、不要分发事件对象
应用逻辑不应当依赖于event对象来正确完成功能,方法接口应该表明哪些数据是必要的。代码不清晰就会导致bug。最好的办法是让事件处理程序使用event对象来处理事件,然后拿到所有需要的数据传给应用逻辑
// 改进的做法
var MyApplication = {
handleClick: function(event) {
this.showPopup(event.clientX, event.clientY)
},
showPopup: function(x, y) {
var popup = document.getElementById(‘popup’)
popup.style.left = x + ‘px’
popup.style.top = y + ‘px’
popup.className = ‘reveal’
}
}
addListener(element, ‘click’, function(event) {
MyApplication.handleClick(event)
})
当处理事件时,最好让事件程序成为接触到event对象的唯一的函数。事件处理程序应当在进入应用逻辑之前针对event对象执行任何必要的操作,包括阻止事件冒泡,都应当直接包含在事件处理程序中
// 改进的做法
var MyApplication = {
handleClick: function(event) {
event.preventDefault()
event.stopPropagation()
this.showPopup(event.clientX, event.clientY)
},
showPopup: function(x, y) {
var popup = document.getElementById(‘popup’)
popup.style.left = x + ‘px’
popup.style.top = y + ‘px’
popup.className = ‘reveal’
}
}
==================================================================
配置数据是指导在应用中写死的值,且将来可能会被修改,包括如下内容
1、URL
2、需要展现给用户的字符串
3、重复的值
4、配置项
5、任何可能发生变更的值
下面是未处理配置数据的做法
// 不好的做法
function validate(value) {
if(!value){
alert(‘Invalid value’)
location.href = ’ /errors/invalid.php’
}
}
function toggleSelected(element) {
if(hasClass(element, ‘selected’)) {
removeClass(element, ‘selected’)
}else{
addClass(element, ‘selected’)
}
}
下面代码中将配置数据保存在了config对象中,config对象的每个属性都保存了一个数据片段,每个属性名都有前缀,用以表明数据的类型(MSG表示展现给用户的信息,URL表示网络地址,CSS表示这是一个className)。当然,也可以将整个config对象放到单独的文件中,这样对配置数据的修改可以完全和使用这个数据的代码隔离开来
// 好的做法
var config = {
MSG_INVALID_VALUE: ‘Invalid value’,
URL_INVALID: ‘/errors/invalid.php’,
CSS_SELECTED: ‘selected’
}
function validate(value) {
if(!value){
alert(config.MSG_INVALID_VALUE)
location.href = config.URL_INVALID
}
}
function toggleSelected(element) {
if(hasClass(element, config.CSS_SELECTED)){
removeClass(element, config.CSS_SELECTED)
}else{
addClass(element, config.CSS_SELECTED)
}
}
===================================================================
将选择器选择到的元素作为对象的静态属性集中到一个地方统一
initializeElements: function() {
var eles = app.Eles
for(var name in eles) {
if(eles.hasOwnProperty(name)) {
this[name] = $(eles[name])
}
}
}
下面是一个例子
// 好的做法
app.Eles = {
widgeDiv: ‘.left-widget div’,
inputResize: ‘.input-resize’,
hr: ‘.he’,
txt: ‘.input-group-btn button’,
cus: ‘#paper-type-cus’,
rulerX: ‘.ruler-x’,
rulerY: ‘.ruler-y’
}
==================================================================
在 JavaScript 开发中,我们大部分时间都在与函数打交道,所以我们希望这些函数有着良好的命名,函数体内包含的逻辑清晰明了。如果一个函数过长,不得不加上若干注释才能让这个函数显得易读一些,那这些函数就很有必要进行重构。 如果在函数中有一段代码可以被独立出来,那我们最好把这些代码放进另外一个独立的函数中。这是一种很常见的优化工作,这样做的好处主要有以下几点。
-
避免出现超大函数。
-
独立出来的函数有助于代码复用。
-
独立出来的函数更容易被覆写。
-
独立出来的函数如果拥有一个良好的命名,它本身就起到了注释的作用。 比如在一个负责取得用户信息的函数里面,我们还需要打印跟用户信息有关的 log,那么打印 log 的语句就可以被封装在一个独立的函数里:
var getUserInfo = function() {
ajax(“http:// xxx.com/userInfo”, function(data) {
console.log("userId: " + data.userId)
console.log("userName: " + data.userName)
console.log("nickName: " + data.nickName)
})
}
改成:
var getUserInfo = function() {
ajax(“http:// xxx.com/userInfo”, function(data) {
printDetails(data)
})
}
var printDetails = function(data) {
console.log("userId: " + data.userId)
console.log("userName: " + data.userName)
console.log("nickName: " + data.nickName)
}
=======================================================================
如果一个函数体内有一些条件分支语句,而这些条件分支语句内部散布了一些重复的代码, 那么就有必要进行合并去重工作。假如我们有一个分页函数 paging,该函数接收一个参数currPage,currPage 表示即将跳转的页码。在跳转之前,为防止 currPage 传入过小或者过大的数字,我们要手动对它的值进行修正,详见如下伪代码:
var paging = function(currPage) {
if (currPage <= 0) {
currPage = 0
jump(currPage) // 跳 转
} else if (currPage >= totalPage) {
currPage = totalPage
jump(currPage) // 跳 转
} else {
jump(currPage) // 跳 转
}
}
可以看到,负责跳转的代码 jump(currPage)
在每个条件分支内部都出现了,所以完全可以把这句代码独立出来:
var paging = function(currPage) {
if (currPage <= 0) {
currPage = 0
} else if (currPage >= totalPage) {
currPage = totalPage
}
jump(currPage) // 把 jump 函数独立出来
}
==========================================================================
在程序设计中,复杂的条件分支语句是导致程序难以阅读和理解的重要原因,而且容易导致一个庞大的函数。假设现在有一个需求是编写一个计算商品价格的 getPrice 函数,商品的计算只有一个规则:如果当前正处于夏季,那么全部商品将以 8 折出售。代码如下:
var getPrice = function(price) {
var date = new Date();
if (date.getMonth() >= 6 && date.getMonth() <= 9) {
// 夏 天
return price * 0.8;
}
return price;
};
观察这句代码:
if (date.getMonth() >= 6 && date.getMonth() <= 9) {
// …
}
这句代码要表达的意思很简单,就是判断当前是否正处于夏天(7~10 月)。尽管这句代码很短小,但代码表达的意图和代码自身还存在一些距离,阅读代码的人必须要多花一些精力才能明白它传达的意图。其实可以把这句代码提炼成一个单独的函数,既能更准确地表达代码的意思, 函数名本身又能起到注释的作用。代码如下:
var isSummer = function() {
var date = new Date()
return date.getMonth() >= 6 && date.getMonth() <= 9
}
var getPrice = function(price) {
if (isSummer()) {
// 夏 天
return price * 0.8
}
return price
}
====================================================================
在函数体内,如果有些代码实际上负责的是一些重复性的工作,那么合理利用循环不仅可以完成同样的功能,还可以使代码量更少。下面有一段创建 XHR 对象的代码,为了简化示例,我们只考虑版本 9 以下的 IE 浏览器,代码如下:
var createXHR = function() {
var xhr
try {
xhr = new ActiveXObject(“MSXML2.XMLHttp.6.0”)
} catch (e) {
try {
xhr = new ActiveXObject(“MSXML2.XMLHttp.3.0”)
} catch (e) {
xhr = new ActiveXObject(“MSXML2.XMLHttp”)
}
}
return xhr
}
var xhr = createXHR()
下面我们灵活地运用循环,可以得到跟上面代码一样的效果:
var createXHR = function() {
var versions = [
“MSXML2.XMLHttp.6.0ddd”,
“MSXML2.XMLHttp.3.0”,
“MSXML2.XMLHttp”
]
for (var i = 0, version; (version = versions[i++]); ) {
try {
return new ActiveXObject(version)
} catch (e) {}
}
}
var xhr = createXHR()
==========================================================================
许多程序员都有这样一种观念:“每个函数只能有一个入口和一个出口。”现代编程语言都会限制函数只有一个入口。但关于“函数只有一个出口”,往往会有一些不同的看法。 下面这段伪代码是遵守“函数只有一个出口的”的典型代码:
var del = function(obj) {
var ret
if (!obj.isReadOnly) {
// 不为只读的才能被删除
if (obj.isFolder) {
// 如果是文件夹
ret = deleteFolder(obj)
} else if (obj.isFile) {
// 如果是文件
ret = deleteFile(obj)
}
}
return ret
}
嵌套的条件分支语句绝对是代码维护者的噩梦,对于阅读代码的人来说,嵌套的 if、else 语句相比平铺的 if、else,在阅读和理解上更加困难,有时候一个外层 if 分支的左括号和右括号之间相隔 500 米之远。用《重构》里的话说,嵌套的条件分支往往是由一些深信“每个函数只能有一个出口的”程序员写出的。但实际上,如果对函数的剩余部分不感兴趣,那就应该立即退出。引导阅读者去看一些没有用的 else 片段,只会妨碍他们对程序的理解。 于是我们可以挑选一些条件分支,在进入这些条件分支之后,就立即让这个函数退出。要做到这一点,有一个常见的技巧,即在面对一个嵌套的 if 分支时,我们可以把外层 if 表达式进行反转。重构后的 del 函数如下:
var del = function(obj) {
if (obj.isReadOnly) {
// 反转 if 表达式
return
}
if (obj.isFolder) {
return deleteFolder(obj)
}
if (obj.isFile) {
return deleteFile(obj)
}
}
=============================================================================
有时候一个函数有可能接收多个参数,而参数的数量越多,函数就越难理解和使用。使用该函数的人首先得搞明白全部参数的含义,在使用的时候,还要小心翼翼,以免少传了某个参数或者把两个参数搞反了位置。如果我们想在第 3 个参数和第 4 个参数之中增加一个新的参数,就会涉及许多代码的修改,代码如下:
var setUserInfo = function(id, name, address, sex, mobile, qq) {
console.log("id= " + id)
console.log("name= " + name)
console.log("address= " + address)
console.log("sex= " + sex)
console.log("mobile= " + mobile)
console.log("qq= " + qq)
}
setUserInfo(1314, “sven”, “shenzhen”, “male”, “138********”, 421354532)
这时我们可以把参数都放入一个对象内,然后把该对象传入 setUserInfo 函数,setUserInfo 函数需要的数据可以自行从该对象里获取。现在不用再关心参数的数量和顺序,只要保证参数对应的 key 值不变就可以了:
var setUserInfo = function(obj) {
console.log("id= " + obj.id)
console.log("name= " + obj.name)
console.log("address= " + obj.address)
console.log("sex= " + obj.sex)
console.log("mobile= " + obj.mobile)
console.log("qq= " + obj.qq)
}
setUserInfo({
id: 1314,
name: “sven”,
address: “shenzhen”,
sex: “male”,
mobile: “138********”,
qq: 421354532
})
======================================================================
如果调用一个函数时需要传入多个参数,那这个函数是让人望而生畏的,我们必须搞清楚这些参数代表的含义,必须小心翼翼地把它们按照顺序传入该函数。而如果一个函数不需要传入任何参数就可以使用,这种函数是深受人们喜爱的。在实际开发中,向函数传递参数不可避免,但我们应该尽量减少函数接收的参数数量。下面举个非常简单的示例。 有一个画图函数 draw,它现在只能绘制正方形,接收了 3 个参数,分别是图形的 width、heigth 以及 square:
var draw = function(width, height, square) {}
但实际上正方形的面积是可以通过 width 和 height 计算出来的,于是我们可以把参数 square 从 draw 函数中去掉:
var draw = function(width, height) {
var square = width * height
}
假设以后这个 draw 函数开始支持绘制圆形,我们需要把参数 width 和 height 换成半径 radius, 但图形的面积 square 始终不应该由客户传入,而是应该在 draw 函数内部,由传入的参数加上一定的规则计算得来。此时,我们可以使用策略模式,让 draw 函数成为一个支持绘制多种图形的函数。
=====================================================================
有一些程序员喜欢大规模地使用三目运算符,来代替传统的 if、else。理由是三目运算符性能高,代码量少。不过,这两个理由其实都很难站得住脚。 即使我们假设三目运算符的效率真的比 if、else 高,这点差距也是完全可以忽略不计的。在实际的开发中,即使把一段代码循环一百万次,使用三目运算符和使用 if、else 的时间开销处在同一个级别里。 同样,相比损失的代码可读性和可维护性,三目运算符节省的代码量也可以忽略不计。让 JS 文件加载更快的办法有很多种,如压缩、缓存、使用 CDN 和分域名等。把注意力只放在使用三目运算符节省的字符数量上,无异于一个 300 斤重的人把超重的原因归罪于头皮屑。 如果条件分支逻辑简单且清晰,这无碍我们使用三目运算符:
var global = typeof window !== “undefined” ? window : this
但如果条件分支逻辑非常复杂,如下段代码所示,那我们最好的选择还是按部就班地编写 if、else。if、else 语句的好处很多,一是阅读相对容易,二是修改的时候比修改三目运算符周围的代码更加方便:
if (!aup || !bup) {
return a === doc
-
? -1
- b === doc ? 1
- aup ? -1
- bup ? 1
- sortInput ? indexOf.call(sortInput, a) - indexOf.call(sortInput, b)
- 0
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数前端工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Web前端开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上前端开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:前端)
前端面试题是我面试过程中遇到的面试题,每一次面试后我都会复盘总结。我做了一个整理,并且在技术博客找到了专业的解答,大家可以参考下:
由于篇幅有限,只能分享部分面试题,完整版面试题及答案可以【点击我】阅读下载哦~无偿分享给大家
感悟
全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。**
[外链图片转存中…(img-r1emGFM3-1713660248396)]
[外链图片转存中…(img-ci3lonN1-1713660248397)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上前端开发知识点,真正体系化!
[外链图片转存中…(img-MR1r2k2I-1713660248397)]
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:前端)
[外链图片转存中…(img-RInWNi6Z-1713660248397)]
前端面试题汇总
前端面试题是我面试过程中遇到的面试题,每一次面试后我都会复盘总结。我做了一个整理,并且在技术博客找到了专业的解答,大家可以参考下:
由于篇幅有限,只能分享部分面试题,完整版面试题及答案可以【点击我】阅读下载哦~无偿分享给大家
感悟
春招面试的后期,运气和实力都很重要,自己也是运气比较好,为了回馈粉丝朋友们(毕竟自己也玩了这么久哈哈哈),整理个人感悟和总结以上。最后祝愿大家能够收获理想offer!!