浅谈前端工程化、模块化、组件化

什么是前端工程化、模块化、组件化?

前端工程化

工程化是一种思想而不是某种技术(当然为了实现工程化我们会用一些技术)

再用一句通俗的话来概括前端工程化:前端工程化就是用做工程的思维看待和开发自己的项目,而不再是直接撸起袖子一个页面一个页面开写

前端模块化
前端工程化是一个高层次的思想,而模块化和组件化是为工程化思想下相对较具体的开发方式,因此可以简单的认为模块化和组件化是工程化的表现形式。

模块化开发,一个模块就是一个实现特定功能的文件,有了模块我们就可以更方便的使用别人的代码,要用什么功能就加载什么模块。

模块化开发的4点好处:

  1 避免变量污染,命名冲突

  2  提高代码复用率

  3 提高维护性

  4 依赖关系的管理

那具体什么是模块化呢?还是举简单的例子,我们要写一个实现A功能的JS代码,这个功能在项目其他位置也需要用到,那么我们就可以把这个功能看成一个模块采用一定的方式进行模块化编写,既能实现复用还可以分而治之,同理在写样式的时候,如果我们需要某种特殊的样式,会在很多地方应用,那么我们也可以采用一定的方式进行CSS的模块化,具体说来,JS模块化方案很多有AMD/CommonJS/UMD/ES6 Module等,CSS模块化开发大多是在less、sass、stylus等预处理器的import/mixin特性支持下实现的

总体而言,模块化不难理解,重点是要学习相关的技术并且灵活运用。

前端组件化
组件化也是工程化的表现形式。

①页面上的每个独立的、可视/可交互区域视为一个组件;
②每个组件对应一个工程目录,组件所需的各种资源都在这个目录下就近维护;
③由于组件具有独立性,因此组件与组件之间可以 自由组合;
④页面只不过是组件的容器,负责组合组件形成功能完整的界面;
⑤当不需要某个组件,或者想要替换组件时,可以整个目录删除/替换。

组件化将页面视为一个容器,页面上各个独立部分例如:头部、导航、焦点图、侧边栏、底部等视为独立组件,不同的页面根据内容的需要,去盛放相关组件即可组成完整的页面。

PS:模块化和组件化一个最直接的好处就是复用,同时我们也应该有一个理念,模块化和组件化除了复用之外还有就是分治,我们能够在不影响其他代码的情况下按需修改某一独立的模块或是组件,因此很多地方我们及时没有很强烈的复用需要也可以根据分治需求进行模块化或组件化开发。

模块化规范

commonJS:commonJS由nodeJS发扬光大,这标志着js模块化正式登场。

一 定义模块

根据commonJS规范,一个单独的文件是一个模块,每一个模块都是一个单独的作用域,也就是说,在该模块内部定义的变量、函数、类,都是私有的,对其他文件不可见,无法被其他模块读取,除非为global对象的属性。

二 模块输出 

模块只有一个出口,module.exports对象,我们需要把模块希望输出的内容放入该对象。

三 加载模块

加载模块用require方法,该方法读取一个文件并且执行,返回文件内部的module.exports对象。

var name = ‘Byron‘;  

function printName(){
    console.log(name);
}  

function printFullName(firstName){
    console.log(firstName + name);
}  

module.exports = {
    printName: printName,
    printFullName: printFullName  

然后加载模块

var nameModule = require(‘./myModel.js‘);
nameModule.printName();

AMD:Asynchronous Module Definition 中文名是一步模块

它是一个在浏览器端模块化开发的规范,由于不是js原生支持,使用AMD规范进行页面开发需要用到对应的函数库,也就是大名鼎鼎的RequireJS,实际上AMD是RequireJS在推广过程中对模块定义的规范化的产出。

requireJS主要解决两个问题:

1 多个js文件可能有依赖关系,被依赖的文件需要早于依赖它的文件加载到浏览器。

2 js加载的时候浏览器会停止页面渲染,加载文件愈多,页面失去响应的时间愈长。

//定义模块

define([‘dependency‘],function(){

  var name = ‘Byron‘;
  function printName(){
     console.log(name);
}

  return {
     printName:printName
   }

})

//加载模块

require([‘myModule‘],function(my){
   my.printName();
})

语法:

requireJS定义了一个函数define,它是全局变量,用来定义模块。

define(id,dependencies,factory)

——id  可选参数,用来定义模块的标识,如果没有提供该参数,脚本文件名(去掉拓展名)

——dependencies  是一个当前模块用来的模块名称数组

——factory 工厂方法,模块初始化要执行的函数或对象,如果为函数,它应该只被执行一次,如果是对象,此对象应该为模块的输出值。

在页面上使用require函数加载模块;
require([dependencies], function(){});
require()函数接受两个参数:
——第一个参数是一个数组,表示所依赖的模块;
——第二个参数是一个回调函数,当前面指定的模块都加载成功后,它将被调用。加载的模块会以参数形式传入该函数,从而在回调函数内部就可以使用这些模块

AMD推崇的是依赖前置,被提前罗列出来并会背提前下载并执行,后来做了改进,可以不用罗列依赖模块,允许在回调函数中就近使用require引入并下载执行模块。

CMD:即common module definition

就像AMD有个requireJS,CMD有个浏览器实现的sea.js,sj要解决的问题和rj一样,只不过在模块定义方式和模块加载时机上有所不同。

cmd是sea.js在推广过程中的规范化产出,sea.js是另一种前端模块化工具,它的出现缓解了requireJS的几个痛点。

define(id, deps, factory)
因为CMD推崇一个文件一个模块,所以经常就用文件名作为模块id;CMD推崇依赖就近,所以一般不在define的参数中写依赖,而是在factory中写。
factory有三个参数:
function(require, exports, module){}
一,require
require 是 factory 函数的第一个参数,require 是一个方法,接受 模块标识 作为唯一参数,用来获取其他模块提供的接口;
二,exports
exports 是一个对象,用来向外提供模块接口;
三,module
module 是一个对象,上面存储了与当前模块相关联的一些属性和方法。

demo
// 定义模块  myModule.js
define(function(require, exports, module) {
  var $ = require(‘jquery.js‘)
  $(‘div‘).addClass(‘active‘);
});

// 加载模块
seajs.use([‘myModule.js‘], function(my){

});

 

AMD与CMD区别

总结如下:

最明显的区别就是在模块定义时对依赖的处理不同。

AMD推崇依赖前置 在定义模块的时候就有声明其依赖的模块

CMD推崇就近依赖 只有在用到某模块的时候再去require

AMD和CMD最大的区别是对依赖模块的执行时机处理不同,注意不是加载的时机或者方式不同。

为什么我们说两个的区别是依赖模块执行时机不同,为什么很多人认为ADM是异步的,CMD是同步的(除了名字的原因。。。)
同样都是异步加载模块,AMD在加载模块完成后就会执行改模块,所有模块都加载执行完后会进入require的回调函数,执行主逻辑,这样的效果就是依赖模块的执行顺序和书写顺序不一定一致,看网络速度,哪个先下载下来,哪个先执行,但是主逻辑一定在所有依赖加载完成后才执行。
CMD加载完某个依赖模块后并不执行,只是下载而已,在所有依赖模块加载完成后进入主逻辑,遇到require语句的时候才执行对应的模块,这样模块的执行顺序和书写顺序是完全一致的。
这也是很多人说AMD用户体验好,因为没有延迟,依赖模块提前执行了,CMD性能好,因为只有用户需要的时候才执行的原因。

  • 目录结构的制定
-- src                        # 源码目录
   |__ index.js               # 项目入口,注入store, 调用render方法
   |__ App.js       # 应用入口,页面整体布局,处理页面路由
   |__ App.less      # 全局共用样式文件
   |__ theme.less      # 项目主题文件
   |__ Components
       |__ ActiveChart        # [组件ActiveChart ]
           |__ index.js       # 组件实现源码文件
           |__ index.less
       |__ AxisTitle       # [组件AxisTitle]
            |__ index.js       # 组件实现源码文件
            |__ index.less
   |__ routes    定义应用的页面容器组件
       |__ Cockpit              # [页面1]
           |__ index.js       # 页面具体业务代码
           |__ indes.less
           |__components   页面的私有组件
       |__ WorkSpace              # [页面2]
             |__ index.js       # 页面具体业务代码
             |__ indes.less
   |__models
       |__ index.js           # 导出封装后的所有store,以及初始化saga
       |__ request.js         # 封装网络请求,比如所所有的方法进行拦截(inspector)
       |__ model1            # [模块1]store基于具体业务模块来编写,方便多页面调用
           |__ actionTypes.js
           |__ actions.js
           |__ reducer.js    封装业务逻辑
       |__ model2           # [模块2]
 |__services
      |__model1.js   封装接口请求
      |__model2.js   封装接口请求
 |__common 公用的工具库
      |__chartUtil
      |__arrayUtil
      |__constants

原文地址:https://www.cnblogs.com/angel648/p/11370327.html

时间: 2024-07-29 18:02:14

浅谈前端工程化、模块化、组件化的相关文章

前端优化带来的思考,浅谈前端工程化

重复优化的思考 这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S左右了,优化度很低),算一算已经做了四轮的全站性能优化了,回顾几次的优化手段,基本上几个字就能说清楚: 传输层面:减少请求数,降低请求量执行层面:减少重绘&回流 传输层面的从来都是优化的核心点,而这个层面的优化要对浏览器有一个基本的认识,比如: ① 网页自上而下的解析渲染,边解析边渲染,页面内CSS文件会阻塞渲染,异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源,新开线

前端优化带来的思考,浅谈前端工程化【转】

重复优化的思考 这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S左右了,优化度很低),算一算已经做了四轮的全站性能优化了,回顾几次的优化手段,基本上几个字就能说清楚: 传输层面:减少请求数,降低请求量执行层面:减少重绘&回流 传输层面的从来都是优化的核心点,而这个层面的优化要对浏览器有一个基本的认识,比如: ① 网页自上而下的解析渲染,边解析边渲染,页面内CSS文件会阻塞渲染,异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源,新开线

浅谈前端性能优化(移动端)

上一篇讲了PC端的部分:前端性能优化(PC端),这次继续说移动端的.相对于PC端的,移动web浏览器上有一些明显的特点:设备的屏幕小.新特性兼容性较好.支持一些比较新的HTML5和CSS3.需要与Native应用交互等.但移动端可用的CPU资源和网络资源极为有限,因此要做好移动端web上的优化往往需要考虑做更多的事情.首先在移动web的前端页面渲染中,PC的优化规则同样适用,此外针对浏览器也要做一些更细节的优化达到更好的效果.需要注意的是,并不是移动端的优化在PC端不适用,而是由于兼容性的原因,

前端web应用组件化(一) 徐飞

https://github.com/xufei/blog/issues/6 Web应用的组件化(一) 基本思路 1. 为什么要做组件化? 无论前端也好,后端也好,都是整个软件体系的一部分.软件产品也是产品,它的研发过程也必然是有其目的.绝大多数软件产品是追逐利润的,在产品目标确定的情况下,成本有两个途径来优化:减少部署成本,提高开发效率. 减少部署成本的方面,业界研究得非常多,比如近几年很流行的“去IOE”,就是很典型的,从一些费用较高的高性能产品迁移到开源的易替换的产品集群,又比如使用Lin

2018 浅谈前端面试那些事

虽然今年没有换工作的打算 但为了跟上时代的脚步 还是忍不住整理了一份最新前端知识点 知识点汇总 1.HTML HTML5新特性,语义化浏览器的标准模式和怪异模式xhtml和html的区别使用data-的好处meta标签canvasHTML废弃的标签IE6 bug,和一些定位写法css js放置位置和原因什么是渐进式渲染html模板语言meta viewport原理 2.CSS 盒模型,box-sizingCSS3新特性,伪类,伪元素,锚伪类CSS实现隐藏页面的方式如何实现水平居中和垂直居中.说说

前端为何要组件化——看山还是山

前端组件化,将页面中的各个部分分割成单独的一部分进行开发,在和别人协同工作的时候能够有效.独立的进行开发,比如你写你的header,我写我的footer,写好了往index里面加,我的模块只影响我,包括css.js. 前端页面中,能够让浏览器渲染出效果需要的其实说到底就3个东西:HTML(结构).CSS(样式).JavaScript(行为).不管是VUE.Angular还是jQuery等框架,之所以叫做框架就是因为他并没有改变本质上的东西,比如jQuery中获取元素 $("#container&

Vue 浅谈前端js框架vue

Vue Vue近几年来特别的受关注,三年前的时候angularJS霸占前端JS框架市场很长时间,接着react框架横空出世,因为它有一个特性是虚拟DOM,从性能上碾轧angularJS,这个时候,vue1.0悄悄 的问世了,它的优雅,轻便也吸引了一部分用户,开始收到关注,16年中旬,VUE2.0问世,这个时候vue不管从性能上,还是从成本上都隐隐超过了react,火的一塌糊涂,这个时候,angular 开发团队也开发了angular2.0版本,并且更名为angular,吸收了react.vue的

Android项目模块化/组件化开发(非原创)

文章大纲 一.项目模块化初步介绍二.项目模块化的两种模式与比较三.大型项目模块化的演进四.项目模块化总结五.参考文章 一.项目模块化初步介绍 1. 前言 在Android开发中,随着项目的不断扩展,项目会变得越来越庞大,而随之带来的便是项目维护成本与开发成本的增加!每次调试时,不得不运行整个项目:每当有新成员加入团队时,需要更多的时间去了解庞大的项目...而为了解决这些问题,团队通常会将项目模块化,以此来降低项目的复杂度和耦合度,让团队可以并行开发与测试,让团队成员更加专注于自己所负责的功能模块

浅谈前端三大框架Angular、react、vue

每个框架都不可避免会有自己的一些特点,从而会对使用者有一定的要求,这些要求就是主张,主张有强有弱,它的强势程度会影响在业务开发中的使用方式.一.Angular,它两个版本都是强主张的,如果你用它,必须接受以下东西: - 必须使用它的模块机制- 必须使用它的依赖注入- 必须使用它的特殊形式定义组件(这一点每个视图框架都有,难以避免) 所以Angular是带有比较强的排它性的,如果你的应用不是从头开始,而是要不断考虑是否跟其他东西集成,这些主张会带来一些困扰. 二.React,它也有一定程度的主张,