- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
。
随着前端应用的日益复杂,我们的项目代码已经逐渐膨胀到了不得不花大量时间去管理的程度了。而模块化就是一种最主流的代码组织方式,它通过把复杂的代码按照功能的不同划分为不同的模块单独维护,从而提高开发效率、降低维护成本。模块化可以使你能够更容易地重用代码。你可以创建一个模块来完成一个特定的功能,然后在多个地方重用这个模块,而不是复制和粘贴代码.
最早期的模块化是通过文件划分的方式,将不同的文件划分为不同的模块,一个文件就对应一个模块,如下图就有2个模块a和b.
想要使用模块的时候就用script标签引入该模块 。
<
script
src
="module-a.js"
></
script
>
<
script
src
="module-b.js"
></
script
>
这种方式存在的问题 。
为了解决以上出现的问题,又有了一种新的模块化方式,便是命名空间,通过将每个模块包裹成一个全局对象来实现,这样的确解决了命名冲突问题,但是仍然存在外部可以修改模块内部内容的问题 。
使用模块 。
<
script
src
="module-a.js"
></
script
>
<
script
src
="module-b.js"
></
script
>
<
script
>
moduleA.method1() moduleB.method1()
//
模块成员可以被修改
moduleA.name
=
'
foo‘ </script>
用立即执行函数实现了私有成员的方式,外部无法修改内部的变量,通过挂载到window对象上来完成模块化的暴露 。
。
前面所提到的几种早期模块化方式都有一个问题,就是必须通过script脚本标签来使用模块,但是如果随着项目规模的增大,忘记加入script标签或者引入了已经删除的模块,就会出现一些问题。也就是说,最好要把引入模块化这个工作放到js代码中去完成,而不只是在html中引入 。
NodeJS里的CommonJS规范是一个很好的模块化方式,CommonJS包含以下几个特征 。
特征中的第4个,require是同步的加载,在Node中只会在启动的时候加载,执行的时候只是去使用,而到了浏览器端,每一次刷新页面都会导致大量的同步模式请求出现,这就无法使用了.
AMD(Asynchronous Module Definition)是 RequireJS 在推广过程中对模块定义的规范化产出,。由于不是JavaScript原生支持,使用AMD规范进行页面开发需要用到对应的库函数,也就是require.js.
AMD这个规范约定每一个模块都必须通过 define 这个函数定义,默认可以接收两个参数, 也可以传递三个参数:
AMD也可以通过require方法来加载对应的模块,require与define的区别是,require只是用来加载,而define是定义一个模块 。
。
。
案例 。
src
├── index.html
├── index.js
├── lib
│ └── require.js // 使用require.js 库
└── modules
├── dataServe.js
└── example.js
//
导入example
define(['example'],
function
(example) { let msg
= "data"
function
showMsg () { console.log(msg, example.getName()); }
return
{ showMsg } })
define(
function
() { let name
= "w"
function
getName () {
return
name }
return
{ getName } })
(
function
() { requirejs.config({ paths: { example:
'./modules/example'
, dataServe:
'./modules/dataServe'
} }) requirejs([
'dataServe'],
function
(d) { d.showMsg() }) })()
<!
DOCTYPE html
>
<
html
lang
="en"
>
<
head
>
<
meta
charset
="UTF-8"
/>
<
meta
http-equiv
="X-UA-Compatible"
content
="IE=edge"
/>
<
meta
name
="viewport"
content
="width=device-width, initial-scale=1.0"
/>
<
title
>
Document
</
title
>
</
head
>
<
body
>
<
script
data-main
="./index.js"
src
="lib/require.js"
></
script
>
</
body
>
</
html
>
问题:
与CommonJS基本保持一致,但是后来也被require.js兼容了 。
ES Module是现在最常用的模块化解决方案,仍然采用了与CommonJS相似的import和export来完成模块的导入和导出 。
在html中,只需要在script标签里加入type="module"就可以导入模块 。
<
script
type
="module"
>
console.log(
'
this is es module
'
)
</
script
>
与普通script标签不同的地方是:
<
script
type
="module"
>
//
es模块会自动开启严格模式
console.log(
this
);
//
undefined
</
script
>
<
script
type
="module"
>
//
es模块都有单独的作用域
let a
=
1
console.log(a);
//
1
</
script
>
<
script
type
="module"
>
//
es模块都有单独的作用域
let a
=
2
console.log(a);
//
2
</
script
>
普通导出:
方式一 用{}包裹需要导出的变量,函数或者类,如果想要改名,可以在导出时用as来改 。
const name = "why"
; const age
= 18
;
function
sum(a, b) {
return
a +
b; } class Person { constructor(name) {
this
.name =
name; } }
//
3.统一导出时使用as关键字给变量起别名
export { name as bName, age, sum as bSum, Person };
方式二 export直接放在变量,函数,类声明之前 。
export const name = "why"
; export const age
= 18
; export
function
sum(a, b) {
return
a +
b; } export class Person { constructor(name) {
this
.name =
name; } }
默认导出 。
方式一:不使用{}包裹变量,函数,类 。
。
const height = 1.88
; export
default
height;
。
方式二:使用{}包裹变量,函数,类,但必须通过as改变名字为default 。
。
const height = 1.88
; export { height as
default
};
。
。
方式一:分别导入,可以通过as来起别名 。
import { name as barName, age, sum, Person as BarPerson, } from
"./bar.js";
方式二:整体导入,通过as来起别名,然后分别使用 。
import * as baz from "./baz.js"
; console.log(baz.name, baz.age); baz.sum(
1, 2
); const person2
=
new
baz.Person("lily"
); console.log(person2);
方式三:导入默认导出的变量,不加{}包裹 。
import height from "./demo.js"
; console.log(height);
。
举例:导入的变量的值会受原模块的影响 。
常用于集中导出,方便后续导入资源 。
。
。
在node环境下,虽说一般都是CommonJS规范的模块化,但是node也做了兼容可以让ES Module正常使用,只要把原来的.js文件改为.mjs就可以正常使用import语法了。import导入的时候还可以导入CommonJS的模块,只是所有CommonJS模块都会被当作默认导出的方式来导入。但是在CommonJS里面,无法使用require去导入ES Module导出的内容,也就是在下面的b.js里面会报错 。
import b from './b.js'
console.log(b.name); // 1234 export let a
= 4
。
。
。
const a = require('./a.mjs'
) // 报错 module.exports
=
{ name:
'1234'
}
。
最后此篇关于前端模块化的文章就讲到这里了,如果你想了解更多关于前端模块化的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
每个人(希望)都在努力实现代码模块化。我想要做的是有 1 个主要的 Sass 文件,它导入我的所有模块,这些模块是局部的,如果需要,这些局部可以调用它们自己的局部组。我想要的是,不是在我的代码库中调用
如何在 xslt 转换中模块化一组重复的输出?例如,我有如下内容(伪代码)。 并
假设我有几个简单的模型驻留在 food.py 中: import peewee as pw db = pw.SqliteDatabase('food.db') class BaseModel(pw.M
我正在开始一个新的 Angular 项目并尝试模块化我的所有代码——我厌倦了拥有大量的 app.js 文件,而且因为我正在为一家公司开发一个平台,所以我的代码整洁且模块化以便于测试、清洁和易于过渡到
所以,有人告诉我,在 nodeJS 中传递 request 和或 response 变量是“不好的做法”。但这意味着你的大部分代码都必须在 server.js 文件中,这使得它变得困惑而且有点难看。
有一个想法:函数(在 FP 中)可以以与 OOP 中的组件类似的方式组成。对于 OOP 中的组件,我们使用接口(interface)。对于函数,我们可以使用委托(delegate)。目标是实现分解、模
有没有办法将 SQL 代码模块化,使其更具可读性和可测试性? 我的 SQL 代码经常变成一长串复杂的嵌套连接、内连接等,难以编写和调试。相比之下,在像 Javascript 或 Java 这样的过程语
我想知道大公司如何倾向于在他们的页面上模块化组件。 Facebook 就是一个很好的例子: There's a team working on Search that has its own CSS,
我正在寻找在 WPF 中构建模块化应用程序模型的解决方案。目前,我使用 Devexpress POCO MVVM 来构建我的 WPF 应用程序,但缺乏模块化的可扩展性,我正在寻找适合我当前设计并允许构
我制作了一个 Gradle 项目,它使用类加载器从子目录资源/文本中加载文本文件。此时它可以工作,但是当我将项目转换为模块化 JavaFX 程序时,相同的类加载器函数会给出 NullPointerEx
假设我有一个通用类模块: export class MyCalc { data = {} ... } 并说我想扩展更多功能: export class MyCalcLoader {
我的模板文件变得越来越大并且过于复杂(大约 200 行(长)代码,9 级缩进),因此它也变得容易出错。我正在寻找一个简单的解决方案,它可以让我轻松访问 $scope 变量和函数。 我的第一个想法是使用
许多人说要将外部 CSS 和 JavaScript 文件的数量保持在最低限度以减少往返时间。例如,Google 建议每个网站最多分别使用两个 CSS 和 JavaScript 文件。 问题是,作为“模
我试图找出为什么我的 Promise 链执行无序,尽管编写了一个非嵌套的 then 链。我的函数已经模块化,以减少链中发生的代码膨胀(我期望有五个 then 方法),并且我不确定这些模块中的某些内容是
关闭。这个问题是opinion-based 。目前不接受答案。 想要改进这个问题吗?更新问题,以便 editing this post 可以用事实和引文来回答它。 . 已关闭 8 年前。 Improv
我使用 create-react-app 创建了一个样板 React 应用程序。 现在,在我的 App.js 文件中 import classes from './App.css'; 我做到了
Java 模块系统是否应该阻止模块通过反射访问其他模块,而不声明正确的模块依赖关系? 例如,在编译这个 hello world Java 11 类时,它从另一个模块调用类,正如预期的那样,它不会编译,
关闭。这个问题需要更多focused .它目前不接受答案。 想改进这个问题吗? 更新问题,使其只关注一个问题 editing this post . 关闭 9 年前。 Improve this qu
我的应用程序上有许多不同的“控制元素”:下拉菜单、选项卡、菜单等。在同一页面上,有许多相同的控件。当编写 JavaScript 来处理与每个控件关联的不同事件时,我试图使我的代码尽可能干燥。挑战之一是
处理以下场景的模块化方式是什么:应用程序具有所有标题标签(h1、h2、h3 等)的通用样式。特定组件 Widget.jsx 可以使用这些标题中的任何一个,但 h1 标签具有特殊样式。在 CSS 的“旧
我是一名优秀的程序员,十分优秀!