摘要:前言前端模塊化,主要是解決兩個問題命名空間沖突,文件依賴管理。目前解決的方法是模塊化命名空間各個模塊的命名空間獨立。模塊化構建工具,等是用來組織前端模塊的構建工具加載器。
前言
前端模塊化,主要是解決兩個問題——“命名空間沖突”,“文件依賴管理”。
坑___命名空間沖突
我自己測試好的代碼和大家合并后怎么起沖突了?
頁面腳本的變量或函數覆蓋了公有腳本的。
坑___文件依賴管理
明明項目需要引入的包都引進來了怎么還報缺少包?
手動管理依賴,有天要更換某個插件,要深入代碼內部進行修改
如下圖,顯示的代碼加載,依賴關系復雜。在F.js中,分不清某個變量是來自C.js,還是E.js
兩次加載同一個模塊。比如引入了兩遍JQ
其他的坑
為了實現腳本復用,將一個很大的公用public文件引入各個頁面中,其中的某些函數,只有個別頁面用到。
某個功能的函數群函數,與另一個功能的函數群擺在一起,使用注釋來分隔。
目前解決的方法是:模塊化
命名空間:各個模塊的命名空間獨立。A模塊的變量x不會覆蓋B模塊的變量x。
模塊的依賴關系:通過模塊管理工具如webpack/requireJS/browserify等進行管理。
模塊化的基本原理——解決命名空間沖突JavaScript的缺陷,首當其沖就是全局變量。這使得每想命名一個變量的時候都要三思又三思,生怕上方無窮遠的地方有一個同事些的代碼和自己沖突。以下是一些防范方法
一、使用命名空間
代碼如下:
//定義 var module = { name: "rouwan", sayName:function(){ console.log(this.name) } } //使用 var a = module.name; console.log(a)
總結:直接修改name不會影響module.name,一定程度保護了命名空間。有兩個缺點,一,外部還是可以修改module的屬性和方法。二,命名空間有時長起來超乎你的想象。適合一些小型的封裝,如一些配置。
二、立即執行函數 + 閉包(實現模塊的基本方法)
立即函數可以創建作用域,閉包則可以形成私有變量和函數
//創建 var module = (function(){ var privateName = "inner"; //私有變量 var privateFunc = function(){ //私有函數 console.log("私有函數") } return { name: "rouwan", //公有屬性 sayName:function(){ //公有函數 console.log(this.name) } } })() //使用 module.sayName(); //"rouwan"
總結:這是目前比較常用的模塊定義方式,可以區分私有成員和公有成員。公有變量和方法,和之前一樣可以直接通過module.name的方式修改。私有變量和方法,是無法訪問的,除非給你個修改私有成員的公有方法。
三、在上述基礎上,引入其他模塊
//定義 var module1 = (function(mod){ var privateName = "inner1"; var privateFunc = function(){ console.log("私有函數1") } return { name : "rouwan1", sayName: function(){ console.log(this.name) }, anotherName:mod.name, //另一個模塊上的公有參數 sayAnotherName:mod.sayName //另一個模塊上的公有方法 } })(anotherModule) //引入了另一個模塊 //使用 module1.sayOtherName()
總結:在一個模塊中可以引入另一個模塊。
四、其他的方式
放大模式等是以往用來管理大型模塊,進行文件拆分的方法。現在webpack等模塊化工具都很完善的情況下,已經顯得有點落后了。就不介紹了。
我了解js模塊是從立即執行函數開始的。但是等到真正使用構建工具的時候,卻發現業界采用的模塊化方案,卻并非是一個一個由立即函數+閉包形成的集群。
而是用了諸如AMD/CMD/CommonJS/ES6模塊等等模塊化實現。
這里面的原因可能有這幾個,一,閉包的性能問題。二,當模塊增多的時候,需要解決模塊間的依賴管理問題。
關于依賴管理,目前項目里碰到了幾個不舒服的地方:
僅此一圖,無須多言
HTML中引入了兩遍的jq,導致腳本報錯。
有一個公用腳本,包含了N多的公用模塊。有些頁面明明只用到了一個模塊,也必須全部加載一遍。
因此,必須使用模塊化管理工具!
幾個概念
包管理工具: 安裝、卸載、更新、查看、搜索、發布包。比如你需要安裝個jq等,通過npm來安裝。npm里有依賴管理,假如jq或者說express升級了,原來代碼不能用了。幫助你解決這個問題的就是npm。
模塊化構建工具:webpack/requireJS/seaJS,等是用來組織前端模塊的構建工具(加載器)。通過使用模塊化規范(AMD/CMD/CommonJS/es6)的語法來實現按需加載。舉個栗子,如果有一天你不用維護一個很長很長的公用腳本文件,這得感謝它。
模塊化規范::AMD/CMD/CommonJS/es6模塊等等規范,規范了如何來組織你的代碼。一般這種方式寫的代碼瀏覽器不認,需要用模塊化構建工具來打包編譯成瀏覽器可以識別的文件。
從我的表格里,可以看出我的推薦搭配———— npm +webpack + es6模塊。
理由如下:
npm與bower比較:
原來bower的使用優勢就是適合前端模塊管理,而npm被視為只適合后端的管理。但是隨著webpack的流行,這個已經毫無疑問是npm勝出了。npm+webpack,可以實現良好的前端模塊管理。
webpack和requireJS比較:
幾種模塊化規范比較:
所以就決定是你了! npm + webpack + es6模塊。
入門實踐在我的另一篇文章 npm + webpack + es6 初體驗
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/80432.html
摘要:純前端開發主要是針對靜態頁面。自主權最大,正常是使用進行輔助開發,上線等。大致原因使用是為了和端的保持同步。四總結對于比較正式的項目,前端技術選型策略一定是產品收益最大化,用戶在首位。 對于前端團隊,可以實現企業受益最大化要點。 一、技術選型的策略 1、保證產品質量 (1)功能穩健:網頁不白屏,不錯位,不卡死;操作正常;數據精準。 (2)體驗優秀:加載體驗,交互體驗,視覺體驗,無障礙訪...
摘要:前端準備前端了解過關了嗎前端基礎架構和硬核介紹技術棧的選擇首先我們構建前端架構需要對前端生態圈有一切了解,并且最好帶有一定的技術前瞻性,好的技術架構可能日后會方便的擴展,減少重構的次數,即使重構也不需要大動干戈,我通常選型技術棧會參考以下三 # 前端準備 :前端了解過關了嗎?前端基礎架構和硬核介紹 showImg(https://segmentfault.com/img/remote/...
摘要:前端準備前端了解過關了嗎前端基礎架構和硬核介紹技術棧的選擇首先我們構建前端架構需要對前端生態圈有一切了解,并且最好帶有一定的技術前瞻性,好的技術架構可能日后會方便的擴展,減少重構的次數,即使重構也不需要大動干戈,我通常選型技術棧會參考以下三 # 前端準備 :前端了解過關了嗎?前端基礎架構和硬核介紹 showImg(https://segmentfault.com/img/remote/...
摘要:前端準備前端了解過關了嗎前端基礎架構和硬核介紹技術棧的選擇首先我們構建前端架構需要對前端生態圈有一切了解,并且最好帶有一定的技術前瞻性,好的技術架構可能日后會方便的擴展,減少重構的次數,即使重構也不需要大動干戈,我通常選型技術棧會參考以下三 # 前端準備 :前端了解過關了嗎?前端基礎架構和硬核介紹 showImg(https://segmentfault.com/img/remote/...
摘要:公司的招聘要求都提到了至少熟悉其中一種前端框架,有前端工程化與模塊化開發實踐經驗相關字眼。我們主要從端公眾號移動端小程序三大平臺進行前端的技術選型,并來說說選其技術的幾大優勢。技術的優勢互聯網前端大潮后,前端出現了大框架,分別是與。 1、技術選型的背景前端技術發展日新月異,互聯網上出現的新型框架也比較多,如何讓新招聘的人員...
閱讀 3021·2021-11-18 10:07
閱讀 3764·2021-11-17 17:00
閱讀 2103·2021-11-15 18:01
閱讀 925·2021-10-11 10:58
閱讀 3372·2021-09-10 10:50
閱讀 3442·2021-08-13 15:05
閱讀 1229·2019-08-30 15:53
閱讀 2639·2019-08-29 13:01