前端开发注意的细节

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

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脚本的代码，就好形成脚本注入的安全隐患，开发过程当中，若是出现此场景仍是，要三思然后行。