内置模块加载器(commonjs规范)的使用

index9.html


<html>
<head>
<title>模块加载器</title>
<script src="jquery-1.7.2.min.js"></script>
<script src="groot.js"></script>
</head>
<body>
<div gt-view="myview">
<span gt-text="name"></span>
</div>
</body>
</html>
<script>
var view = groot.view("myview", function (vm, ve) {
vm.name = "";
})
var m=require("./moudle");
view.name= m.txt;
groot.sweep();
</script>

这里的某块加载器实现的是commonJs规范,完全和nodeJs的模块加载器相同

模块定义


exports.txt = "hello word";
module.exports={
"name":"张三"
}

require加载文本 require("./xxx.html!text");

require加载css require("./xxx.css!css");

默认加载js,并且加载js 可以省略后缀名

这里有不懂得可以查下commonJs的规范

时间: 2024-07-31 14:04:45

内置模块加载器(commonjs规范)的使用的相关文章

自研模块加载器(一) 模块系统概述与自定义模块规范书写规定

模块系统概述 CommonJs/AMD/CMD/ES6 Modules 什么是模块化? 模块化就是把系统分离成独立的功能的方法,需要什么功能,就加载什么功能 当一个系统越来越复杂时候,我们会遇到这些问题 1. 命名冲突 2. 文件依赖 使用模块化开发可以避免以上问题,并提升开发效率 1. 可维护性 2. 可复用性 在生产角度,模块化是一种生产方式,这种生产方式效率高,维护成本低. 模块化开发演变 1. 全局函数 早期开发中,将重复的代码封装成函数,将多个函数放在一个文件中. 缺点: 污染全局变量

浏览器端的javascript加载器

commonJS,定义了一种同步加载脚本的规范.对于浏览器端而言,因为js脚本都是在远端,用同步的方式可能会长时间阻塞线程.因此,浏览器端的js加载器并不会严格按照commonJS来做.seajs作为一个试图遵循commonJS规范的加载器,是在规范的基础上在外面包一层define,来异步加载js,以下是seajs官网的一个例子: // 所有模块都通过 define 来定义 define(function(require, exports, module) { // 通过 require 引入依

JS模块加载器加载原理是怎么样的?

路人一: 原理一:id即路径 原则.通常我们的入口是这样的: require( [ 'a', 'b' ], callback ) .这里的 'a'.'b' 都是 ModuleId.通过 id 和路径的对应原则,加载器才能知道需要加载的 js 的路径.在这个例子里,就是 baseUrl + 'a.js' 和 baseUrl + 'b.js'. 但 id 和 path 的对应关系并不是永远那么简单,比如在 AMD 规范里就可以通过配置 Paths 来给特定的 id 指配 path. 原理二:crea

js模块化/js模块加载器/js模块打包器

之前对这几个概念一直记得很模糊,也无法用自己的语言表达出来,今天看了大神的文章,尝试根据自己的理解总结一下,算是一篇读后感. 大神的文章:http://www.css88.com/archives/7628(大神的文章写的很详细,建议先看完大神的文章) 一.js模块化 什么是js模块化,我们从历史说起. 1.一开始我们怎么写脚本?就是在html文件中用<script></script>写代码 这种方式的缺点:代码复用靠复制,基本是全局变量. 2.后来我们用js文件写代码,用<

再唠叨JS模块化加载之CommonJS、AMD、CMD、ES6

Javascript模块化编程,已经成为一个迫切的需求.理想情况下,开发者只需要实现核心的业务逻辑,其他都可以加载别人已经写好的模块. Javascript社区做了很多努力,在现有的运行环境中,实现"模块"的效果. CommonJS CommonJS定义的模块分为:  模块引用(require)    模块输出(exports)       模块标识(module) CommonJS Modules有1.0.1.1.1.1.1三个版本: Node.js.SproutCore实现了 Mo

类的加载器 ClassLoader

先说明类的加载过程: 当程序主动使用某个类时,如果该类还未被加载到内存中,则系统会通过如下三个步骤来对该类进行初始化: 而关于ClassLoader: 类加载器是用来把类(class)装载进内存的.JVM 规范定义了两种类型的类加载器:启动类加载器(bootstrap)和用户自定义加载器(user-defined class loader). JVM在运行时会产生3个类加载器组成的初始化加载器层次结构 ,如下图所示: 举例如下: public class TestClassLoader { pu

AMD加载器实现笔记(五)

前几篇文章对AMD规范中的config属性几乎全部支持了,这一节主要是进一步完善.到目前为止我们的加载器还无法处理环形依赖的问题,这一节就是解决环形依赖. 所谓环形依赖,指的是模块A的所有依赖项的依赖中有没有依赖A模块本身的模块.如果有那就说明存在环形依赖.所以检验的方式是利用递归,检查一个模块的依赖的依赖项中有没有依赖A模块,以及依赖项的依赖项的依赖项中有没有A模块,核心代码如下: function checkCircleRef(start, target){ var m = modules[

AMD加载器实现笔记(二)

AMD加载器实现笔记(一)中,我们实现了一个简易的模块加载器.但到目前为止这个加载器还并不能称为AMD加载器,原因很简单,我们还不支持AMD规范中的config配置.这篇文章中我们来添加对config的中baseUrl和packages的支持.API设计如下: 1 require.config({ 2 baseUrl: "./", 3 packages: [{ 4 name: "more", 5 location: "./more" 6 }, {

AMD加载器实现笔记(四)

继续这一系列的内容,到目前为止除了AMD规范中config的map.config参数外,我们已经全部支持其他属性了.这一篇文章中,我们来为增加对map的支持.同样问题,想要增加map的支持首先要知道map的语义. 主要用于解决在两个不同模块集中使用一个模块的不同版本,并且保证两个模块集的交互没有冲突. 假设磁盘有如下文件: 当'some/newmodule'请求'foo'模块时,它将从foo1.2.js总得到'foo1.2'模块:当'some/oldmodule'请求'foo'模块时它将从foo