前端开发注意的细节
此博文内容比较浅显,但是就目前项目开发中,仍然发现这些细节被同学们所忽略,写此文权当给给同学们做个引子,有则改之,无则加勉,做的更好的同学请在文后做个评论,以供大家学习参考。
js设置默认值
在ES6之前,没有设置默认值的语法,大家通常使用以下方式设置默认值:
function fn(num) {
// 设置默认值
num = num || 1;
console.log(num);
}
但是问题在于,fn函数的参数num为0、false、null、undefined、空字符串的时候,num都会被赋予1的默认值,显然:传参为0时,并非如我们所愿设置为默认值1。
此时最好以一下判断方式,来赋予默认值
function fn(num) {
num = typeof num === 'undefined' ? 1 : num;
console.log(num);
}
默认值,顾名思义,实在没有给函数传递参数是,为该参数默认的值,翻译成js代码,就是该参数为undefined的时候,才使用该值。因此,以undefined为目标来判断相对比较科学,因为其他几个类型的数据,虽然,从其字面值上来讲在某些时候确实可以和undefined相等(==),但是从数据上来讲,其实有实质内容的,也可以说是占有实际内存空间的,并不能和undefined完全等价(===)。
多个条件并列
一般在业务比较复杂的地方,经常会出现多个条件并列的if语句,很多同学的做法是多个条件表达式同是并列显示一行,这样执行起来当然没有问题,但是非常不方便阅读,编辑器没有设置代码自动换行,需要拖动很长的水平滚动条,等看完后面的条件,前面的也忘记的差不多了;也不符合每行不超过80个字符的编码风格,并且如果配置了eslint等也会提示警告。
其实完全可以把多个条件,多行并列显示,如下:
...
if(
a === 1 &&
b === 1 &&
c === 1 ||
....
) {
// do something
}
...
看上去非常清晰,每个条件和上下文的关系也很容易阅读记忆。
同理,在使用web component方式开发时,经常需要向组件传递一堆数据,如:
<Component data1={data1} data2={data1} data3={data3} data4={data4} data5={data5} ... />
把很多数据传递写到一行代码中,同样也会造成上述阅读、记忆不便的问题,稍加改造,分行编写,就好清晰很多,如:
<Component
data1={data1}
data2={data1}
data3={data3}
data4={data4}
data5={data5}
...
/>
模板语言缩进问题
现在很多项目使用mvvm的框架来开发,像AngularJS、RegularJS、VueJS都有其自己的模板系统,也自有一套语法规则,一般情况下,模板语言都将会有处理条件分支的if-else语句,也有遍历数据的each语句,在开发过程中,有些同学为了体现html的结构,在编写if-else和each语句是,不缩进其下层代码,如(模板语法参考RegularJS):
<div>
{#each list as item}
<span>{item}</span>
{/each}
</div>
有部分同学,可能为了体现div和span父子关系,在<span>标签所在行,并没有进行层级缩进,上述代码只有一层each语句,看起来,还能接受,但是如果再加上条件判断,如:
<div>
{#each list as item}
{#if item < 10}
<span>小于10的数字:{item}</span>
{#else}
<span>小于10的数字:{item}</span>
{/if}
{/each}
</div>
一眼看上去,each和if-else搅和在一起,可读性特别差。从我理解来说,组件模板中,不知能只注意html的结构,因为除了html,逻辑处理也是我们表达程序目的内容,如果将只为了程序html结构,导致代码可读性很差,代码整体交给不明了,无疑会增加代码维护成本。特别是对于患有强迫症的程序员,眼里根本容不得一个多余的空格,哪怕是在行尾,也要将其干掉。
我推荐的模板代码格式,逻辑块(each、if、else等)和组件标、html标签层级分明,对于逻辑要输出的内容一目了然。如:
<div>
{#each list as item}
{#if item < 10}
<span>小于10的数字:{item}</span>
{#else}
<span>小于10的数字:{item}</span>
{/if}
{/each}
</div>
可以考虑使用一些数据结构
最初学习编程的时候,老师就说:程序设计=数据结构+算法,不过后来在业务开发中,很少去直接使用数据结构和算法,这些东西都被编程语言封装过了,但是少用并不代表不用,特别是当下云计算、大数据、人工智能这些技术的星期必然算法密不可分,扯的有点远了,其实在日常业务开发中,如果能留意还是能发现一些数据结构的应用场景的。
如二叉树进行排序、寻找临界值(最大、最小值),如果有这方面的需求也可以考虑;还有队列,在开发买票业务是有排队场景的时候也可以用上。还有其他数据结构,如堆、栈也有其运用的场景。
之前,在开发某个业务系统,有个前端的需求,需要对一个列表(数组)进行拖动排序,如:拖动A到B的位置,其过程是:第一步将A从列表中移除,第二步将A插入到B所在的位置。上述过程,看似简单,如果纯粹使用JS数组来处理的话,此处需要将数组元素A拿掉,A之后的元素向前移动;第二步,将A插入到B的位置,可以分两步,第一B包括之后的元素,向后移,然后把A放到B的位置,使用程序处理起来还是比较复杂的,此处如果将该列表构造成一个链表,在移除和插入的位置,只需要修改目标位置的前后和目标元素的前后指针即可,运算次数会降低不少。
当然,数据比较的少的时候,JS数组的API就能简单的处理,使用数据结构解决问题,有点大炮打蚊子的感觉,但是我认为还是有必要的,数据是一个动态的东西,现在少未来未必少,比如上述中的需求的,后期列表元素的数量就上升到了几百个。
局部loading
这个问题可能是交互设计的问题,不过也可以是前端问题。局部loading的名字是我自己起的,和其对应的是全局loading,在当下单页应用横行的时代,数据都是前后端分离,所有的数据都是用过ajax请求获取,为了交互同意,很多系统在设计的时候,请求loading的过程都会弹出一个全局遮罩层上面有个loading图标,在请求时屏蔽页面上所有的操作,这就是我所谓的全局loading。而局部loading则与之相反,那个操作点发出的请求,只需要在对应的操作点上显示loading即可如:点击按钮A,发送一个请求更新列表,只需要在按钮A上面显示loading或者loading的文案。
按照我的观点是反对所有地方都使用全局loading的,因为这样违背了异步请求的初衷,异步请求本来就是把请求过程放到后台,不影响前台的操作,等拿到响应数据,再把数据更新到前台,而全局loading,把整个前台界面全部屏蔽遮罩,无法进行任何操作,比如:页面滚动加载数据,此时页面被全局loading屏蔽、遮挡,页面内容不能完整查看,所有操作都收到限制,如果请求时间过长,体验很很差。
XXS攻击
关于XXS攻击的内容,网上很多,也是日常web开发中经常要注意的一个安全问题,并且现在很多前端框架对此也有一定的而防范。我要说的,也是一个XXS相关且容易忽略的点:从页面URL中获取参数,并把参数的内容输出到页面上,比如,URL中有一个a参数,在前端代码中,使用js直接获取参数后,没有通过XSS相关编码的处理,直接或者间接的输出到页面上,此时a参数中含有JS脚本的代码,就好造成脚本注入的安全隐患,开发过程中,如果出现此场景还是,要三思而后行。