模块化相比于传统的模式有什么优势?

2024-04-29    分类: 网站建设

如今模块化的 JavaScript 的开发越来越火热,无论是模块加载器还是优秀的 JavaScript 模块,都是层出不穷。既然这么火,肯定是有存在的理由,肯定是解决了某些实际问题。很多没接触过模块化 JavaScript 开发者不禁要问,我真的需要模块化吗,模块化相比于传统的模式有什么优势?

JavaScript 本身是没有模块化支持的,很多语言都有,就连CSS都有这样的加载方式。

@import "fed.css";

虽然因为性能问题不推荐CSS这样来进行加载,但这是一种模块化的思想,这种思想对于 JavaScript 来说很有用。幸好JavaScript是一门灵活的语言,可以通过下面这段代码来进行动态加载 JavaScript 文件。

var script = document.createElement( 'script' ), head = document.head;

script.src = 'http://example.com/test.js'; script.async = 'async'; head.insertBefore( script, head.firstChild );

传统的加载方式必须在页面中放置一个 script 标签来进行加载。

<script type="text/javascript" src="http://example.com/test.js"></script>

更好的分离

那如果要加载多个就得放置多个 script 标签,如果是加载模块的话,拿 easy.js 来说,页面中始终只要引用 easy.js 即可,这样对于 HTML 和 JavaScript 分离很有好处,在某些场景下这个分离度很重要。

就拿我司的情况来说吧。后端的 view 层并不是由我们前端来开发的,项目上线的时候,前端只能更新 CSS 和 JS 文件,HTML 文件动不了。如果前端要在该页面新增一个 JavaScript 文件的引用是很麻烦的,因为后端程序的更新都要严格按照流程来并有固定的更新时间,如果是用模块加载的方式不用再理会后端的更新。当然,你也许会说,如果原页面中已经有 JavaScript 文件,我直接在原文件中加代码不就行了,那么接下来说说直接在原文件中新增代码会碰到什么样的问题。

更好的代码组织方式

如果单个文件越来越大,维护起来出问题的几率也会越来越大,一个人开发还好,如果是多人开发,不同的代码风格,超多的业务逻辑混杂在一起,不要说维护了,光想想都蛋痛。模块式的开发,一个文件就是一个模块,控制了文件的粒度,每个模块可以专注于一个功能。正所谓一个萝卜一个坑,多人开发时,各自管好自己坑里的萝卜就行了,这也正是 OOP 的思想。

按需加载

还是围绕单个文件来说事,当文件大到一定的程度,性能问题也随之而来了。合并文件是能减少请求,这是会带来性能的提升,但是当文件大到一定的体积时,此时的下载时间可能并不会比多个小文件的下载时间更短。此时就需要权衡请求数和文件体积的关系了。

单文件还有一个问题,那就是缓存是否能充分的利用好。如果一个大体积的文件内包含了超多的业务逻辑和复杂的功能,而这个文件同时又被很多页面引用到。比如在某页面,实际只用到了该文件一个很少的功能,那么其他的代码对于该页面来说就是多余的,浪费了加载流量。你或许会说,这个文件虽然大,但是它第一次加载的时候就被缓存过了,尽管在某页面只用到了极少部分的功能,但只要缓存过,加载还是挺快的。是的,如果情况有这么理想肯定是好事。但是,往往理想和现实都会有差距,如果产品的迭代更新太快,业务需求一天一个样,那么该文件就会三天两头的更新,更新可能是一个很小的功能,但是这样的更新对于刷新缓存的代价可是很大的。如果确实有这种情况,就说明这种设计确实是有问题。如果能合理的对文件进行模块化的管理,那么可以尽量减少不必要的加载,尽量减少刷新大文件的缓存带来的损失,这也需要权衡好,比如将很少更新的合并成一个文件,常更新的独立成模块。

避免命名冲突

JavaScript 本身是没有命名空间的,为了避免命名冲突,经常会使用对象和闭包的办法来避免。用对象仅仅是降低了冲突的概率而已,拿经常使用 jQuery 的开发来说,无论是往 $ 上扩展还是在 $.fn 上扩展,人多了难免会起冲突。或者用自定义的对象,搞个好几层,不光是写起来难记,这样的调用也会在性能上打折扣的。模块化就很好的解决了这个问题,在该模块内的任何形式的命名都不会再和其他模块有冲突,你想起啥名都行了。当然,你硬要在模块内部给 window 上挂一堆东西,我也没办法。

既然每个模块都是封闭式的,那么模块之间如何通信呢?接口的设计那是必须的。很简单,对于像 seajs 这种 CMD 规范的,需要使用自定义的关键字来向外部暴露一个接口。

define(function( require, exports ){ var hello = 'hello world'; // 向外部暴露该模块的接口 exports.hello = hello; });

easy.js 遵循 AMD 规范,暴露接口更简单,直接用 return 关键词即可。

define( 'hello', function(){ var hello = 'hello world'; // 向外部暴露该模块的接口 return hello; });

更好的依赖处理

传统的开发模式,如果 B 文件要依赖 A 文件,那么必须在 B 文件前面用 script 的形式先加载好 A 文件。如果有一天,B 文件不再需要依赖 A 文件,或者要增加依赖文件 C,那么又回到了我说的第一个问题上。如果这个 B 文件被 N 个页面在调用,而且页面还跨业务站点,那改起来简直就是噩梦啊。如果是用模块化,只需要在模块内部声明好依赖就行了,增加删除都直接修改模块即可。调用的时候也不用管该模块依赖了哪些其他模块,放心的用就是了。

本文来自成都品牌网站建设网站设计公司-创新互联

本文标题:模块化相比于传统的模式有什么优势?
网页链接:https://www.cdcxhl.com/news47/326547.html

成都网站建设公司_创新互联,为您提供动态网站虚拟主机ChatGPT企业网站制作软件开发网站营销

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联

小程序开发