前端开发注意的细节

发布时间:2019-08-19 发布网站:脚本宝典
脚本宝典收集整理的这篇文章主要介绍了前端开发注意的细节脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。

此博文内容比较浅显,但是就目前项目开发中,仍然发现这些细节同学们所忽略,写此文权当给给同学们做个引子,有则改之,无则加勉,做的更好的同学请在文后做个评论,以供大家学习参考。

js设置默认值

在ES6之前,没有设置默认值的语法,大家通常使用以下方式设置默认值:

function fn(num) {
    // 设置默认值
    num = num || 1;
    console.LOG(num);
}

但是问题在于,fn函数的参数num为0、falsenull、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脚本的代码,就好造成脚本注入的安全隐患,开发过程中,如果出现此场景还是,要三思而后行。

脚本宝典总结

以上是脚本宝典为你收集整理的前端开发注意的细节全部内容,希望文章能够帮你解决前端开发注意的细节所遇到的问题。

如果觉得脚本宝典网站内容还不错,欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。