JS编程常识

时间  2019-12-12
标签 编程 常识 栏目 JavaScript 繁體版
原文   原文链接

一.UI层的松耦合

松耦合就是要求各层遵循“最少知识原则”，或者说是各层各司其职，不要越权：javascript

  • HTML：结构层css

  • CSS：表现层html

  • JS：行为层java

对于各层的职能，有一句比较贴切的解释：HTML是名词（n），CSS是形容词（adj）和副词（adv），JS是动词git

由于三层联系紧密，实际应用中很容易越权：github

耦合

1.从css中分离js

尽可能不要用css表达式，若是非要用也应该把相应的代码放在hack中，便于维护web

2.从js中分离css

不要用ele.style.attr及ele.cssText，应该用操做类名代替编程

3.从html中分离js

不要用onclick等属性直接指定事件处理函数，应该用添加事件处理器方式代替设计模式

通常不要用<script>标签直接嵌入js代码，尽可能放在外部js文件中。固然，对于功能单一且不须要复用的代码能够直接嵌在HTML中，例如表单验证代码浏览器

4.从js中分离html

不要直接用innerHTML硬编码，能够用如下3种方式代替：

  1. 用Ajax从服务端获取HTML串，避免硬编码

  2. 用简单的客户端模版，有2种实现方式：

    • 用注释携带模式串

    • 用script标签携带模式串，把type属性设置为浏览器没法识别的值，还应该给script标签设置id属性以便于获取模式串，例如：

      <script type="text/x-my-template" id="list-item">
    <li><a href="%s">%s</li>
</script>

      推荐使用这种方式，由于更容易获取模式串

  3. 用复杂的客户端模版，好比jade、ejs

P.S.由于html与css的解耦与js编程没有关系，因此书中也没有相应内容

二.少用全局变量

1.全局变量带来的麻烦

  • 命名冲突

  • 代码不健壮，函数须要的全部外部数据都应该用参数传进来，而不要用全局变量传参

  • 难以测试，须要重建整个全局环境

2.隐式全局变量

不要用隐式全局变量方式声明全局变量，建议全部变量声明都带上var关键字

为了不隐式全局变量，还应该开启严格模式（”use strict”;），[IE10+]支持

3.单全局变量方式

  1. 用命名空间，提供一个避免命名空间冲突的方法：

    // 顶级命名空间
var app = {
    /*
     * 建立/获取子命名空间，支持链式调用
     */
    namespace: function(ns) {
        var parts = ns.split("."),
            object = this,
            i, len;

        for (i = 0, len = parts.length; i < len; i++) {
            if (!object[parts[i]]) {
                object[parts[i]] = {};
            }
            object = object[parts[i]];
        }

        return object;  // 支持链式调用
    }
}

// 测试
app.namespace("Consts").homepage = "http://ayqy.net/";
app.namespace("Consts").author = "ayqy";
// http://ayqy.net/, ayqy
alert(app.Consts.homepage + ", " + app.Consts.author);

  2. 模块化

    AMD/CMD，一点扩展知识以下：

    CommonJS是一套理论规范（好比js的理论规范是ES），而SeaJS, RequireJS都是对CommonJS的Modules部分的具体实现

    CommonJS是面向浏览器外(server端)的js制定的，因此是同步模块加载，SeaJS是CommonJS的一个实现，而RequireJS虽然也是对CommonJS的一个实现，但它是异步模块加载，算是更贴近浏览器的单线程环境

    总结：CommonJS的Modules部分提出了模块化代码管理的理论，为了让js能够模块化加载，而RequireJS, SeaJS等各类实现能够称为模块化脚本加载器

    • CMD:Common模块定义，例如SeaJS

    • AMD:异步模块定义，例如RequireJS

    都是用来定义代码模块的一套规范，便于模块化加载脚本，提升响应速度

    CMD与AMD的区别：

  • CMD依赖就近。便于使用，在模块内部能够随用随取，不须要提早声明依赖项，因此性能方面存在些许下降（须要遍历整个模块寻找依赖项目）

  • AMD依赖前置。必须严格声明依赖项，对于逻辑内部的依赖项（软依赖），以异步加载，回调处理的方式解决

4.零全局变量方式

用IIFE（匿名函数当即执行）实现，针对不须要复用的功能模块能够用IIFE彻底消除全局变量，因此通常IIFE都是用来辅助命名空间/模块化方式的

三.事件处理

1.典型用法（很差）

// 事件处理器
function handleClick(event) {
    var popup = document.getElementById("popup");
    popup.style.left = event.clientX + "px";
    popup.style.top = event.clientY + "px";
    popup.className = "display";
}

// 添加事件处理器
ele.addEventListener("click", handleClick);

2.分离应用逻辑（稍好一点）

var app = {
    // 事件处理
    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 = "display";
    }
};

// 添加事件处理器
// P.S.事件处理器是一个方法声明，而不是方法调用，没法传参，因此须要多一层匿名函数
ele.addEventListener("click", function() {
    app.handleClick(event);
});

3.不要传递事件对象（最好）

var app = {
    // 事件处理
    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 = x + "px";
        popup.className = "display";
    }
};

// 添加事件处理器
ele.addEventListener("click", function() {
    app.handleClick(event);
});

“不要传递事件对象”是一条优化原则，在js高程的优化部分也有提到过，但本书给出了详细理由

直接传递事件对象存在如下缺点：

  1. 接口定义不明确，参数做用未知

  2. 难以测试（重建一个event对象？）

四.少与null比较

1.检测基本值

用typeof检测，但要注意typeof null返回object，这不太科学，由于js认为null是一个空对象的引用

但用 === null检测DOM元素是合理的，由于null是document.getXXByXXX的可能输出之一

2.检测引用值

instanceof并不能准确地检测子类型，并且不要用它检测fun和arr，由于不能跨frame

  1. 检测fun

用typeof检测通常方法；用in检测DOM方法

  1. 检测arr

用Object.prototype.toString.call(arr) === "[Object Array]"检测

注意：ES5有原生的Array.isArray()方法，[IE9+]支持

3.检测属性

用in配合hasOwnProperty()检测

注意：[IE8-]的DOM元素不支持hasOwnProperty()，用的时候要先检测

五.分离配置数据

1.配置数据有哪些？

  1. 硬编码的值

  2. 未来可能会变的值

好比：

  • URL

  • 须要显示给用户的字符串

  • 重复使用的惟一值

  • 设置（例如每页显示多少列表项）

  • 可能会变的任何值（很差维护的东西都算配置数据）

2.分离配置数据

先从应用逻辑中分离出配置数据，最简单的能够把全部配置数据分级存放在自定义的config对象中

3.存储配置数据

能够用js文件存储配置数据，便于加载，但配置数据要严格符合js语法，容易出错。做者建议把配置数据存储为格式简单的属性文件再用工具转换为JSON/JSONP/js格式文件用于加载，做者推荐一个本身写的工具props2js

六.抛出自定义错误

1.Error的本质

用来标志出乎意料的东西，避免静默失败，便于调试

2.用js抛出错误

不要抛其它类型，要抛Error对象，由于兼容性，例如：

throw "error: invalid args";    // 有些浏览器不显示该字符串

3.抛出错误的优势

精肯定位错误，建议错误信息格式：函数名 + 错误缘由

4.什么时候该抛出错误

只抛经常使用方法（工具方法）中的错误，通常原则：

  1. 修复了奇葩bug以后，应该添几个自定义错误，防止错误再次发生

  2. 若是写代码的时候以为某些点可能引发大麻烦，就应该抛出自定义错误

  3. 若是代码是写给别人用的，应该想一想别人使用的时候可能遇到哪些问题，应该在自定义错误中给出提示

5.try-catch语句

finally不经常使用，由于会影响catch中的return

不要留空的catch块，静默失败可能会把问题变得更麻烦

6.几种错误类型

能够抛出原生的几种错误类型实例，配合instanceof作针对性错误处理

P.S.关于具体的几种错误类型以及错误处理的更多信息，请查看黯羽轻扬：JS学习笔记8_错误处理

七.尊重对象全部权

1.哪些对象不属于咱们？

  • 原生对象（Object、Array等等）

  • DOM对象（好比document）

  • BOM对象（好比window）

  • 库对象（好比JQuery）

2.具体原则

  1. 不要重写方法

  2. 不要添新方法，非要改库功能的话，能够给库开发插件

  3. 不要删除方法，不想用的不要删除，标明过期便可

    注意：delete对原型属性无效，只对实例属性有用

    function Fun() {
    this.attr1 = 1; // 实例属性
}
Fun.prototype.attr2 = 2;    // 原型属性

// 测试
var obj = new Fun();
alert(obj.attr1 + ", " + obj.attr2);    // 1, 2
delete obj.attr1;
delete obj.attr2;
alert(obj.attr1 + ", " + obj.attr2);    // undefined, 2
delete Fun.prototype.attr2;
alert(obj.attr1 + ", " + obj.attr2);    // undefined, undefined

3.更好的方式

  1. 基于对象的继承

    也就是clone一个新对象，新对象是属于本身的，能够随便改

  2. 基于类型的继承

    注意：不要继承DOM/BOM/Array，由于支持性很差

    P.S.关于对象继承/类型继承的具体实现，请查看黯羽轻扬：从新理解JS的6种继承方式

  3. 外观模式

    其实就是组合，由于继承/组合都是实现代码复用的方式，关于外观模式的更多信息请查看黯羽轻扬：设计模式以外观模式（Facade Pattern）

    一点题外话：facade与adapter的区别是前者建立了新接口，后者只是实现了已存在的接口，做者一针见血

4.polyfill的优缺点

polyfill 是“在旧版浏览器上复制标准 API 的 JavaScript 补充”。“标准API”指的是 HTML5 技术或功能，例如 Canvas。“JavaScript补充”指的是能够动态地加载 JavaScript 代码或库，在不支持这些标准 API 的浏览器中模拟它们。由于 polyfill 模拟标准 API，因此可以以一种面向全部浏览器将来的方式针对这些 API 进行开发，最终目标是：一旦对这些 API 的支持变成绝对大多数，则能够方便地去掉 polyfill，无需作任何额外工做。

关于polyfill的更多信息请查看博客园：[译]shim和polyfill有什么区别?

优势：不须要的时候很容易去掉

缺点：若是polyfill的实现与标准不彻底一致就麻烦了

建议不要用polyfill，应该用原生方法 + 外观模式来代替，这样更灵活

5.防篡改

应该开严格模式，由于非严格模式下静默失败难以调试

八.浏览器检测

1.UA（User Agent）检测

非要UA检测的话，尽可能向后检测而不是向前，由于后面的不会再变了

P.S.做者认为不用管UA会不会变，理由是会设置UA的用户应该也知道这样作的后果

2.特性检测

特性检测的通常格式以下：

  1. 尝试标准方式

  2. 尝试特定浏览器的实现方式

  3. 不支持的话要给出逻辑反馈（好比return null）

例如：

function setAnimation (callback) {
    // 1.尝试标准方式
    if (window.requestAnimationFrame) {                 // standard
        return requestAnimationFrame(callback);
    }
    // 2.尝试特定浏览器的实现方式
    else if (window.mozRequestAnimationFrame) {         // Firefox
        return mozRequestAnimationFrame(callback);
    }
    else if (window.webkitRequestAnimationFrame) {      //WebKit
        return webkitRequestAnimationFrame(callback);
    }
    else if (window.oRequestAnimationFrame) {           // Opera
        return window.oRequestAnimationFrame(callback);
    }
    else if (window.msRequestAnimationFrame) {          // IE
        return window.msRequestAnimationFrame(callback);
    }
    // 3.不支持的逻辑反馈
    else {
        return setTimeout(callback, 0);
    }
}

3.杜绝特性推断

不能根据一个特性推断另外一个特性，由于长得像鸭子的东西不必定也像鸭子同样呱呱叫

4.杜绝浏览器推断

不要根据特性去推断浏览器，好比典型的：

if (document.all) { // IE
    // ...
}

这样作是不对的，不该该尝试用特征去描述一个东西，很容易由于条件过少或者过多致使描述不许确

5.到底应该用哪个？

尽可能用直接特性检测，不行才用UA检测。至于推断，就根本不考虑了，没有任何理由去用推断

参考资料

  • 《Maintainable JavaScript》
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程