Dojo require()和AMD(1.7) [英] Dojo require() and AMD (1.7)

查看:170
本文介绍了Dojo require()和AMD(1.7)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个heckuva时间过渡到Dojo和新的AMD结构,我真的希望有人可以在整个概念上散发光明。在过去几个星期里,我一直住在Google上,试图找到关于使用情况的信息,但是使用这种方式的结构和设计模式趋势。



我觉得奇怪的是,对于一个比较复杂的JavaScript应用程序,比如一个主页面,需要创建和设计Dijits,创建DOM元素等等需要在AMD系统之前(或至少没有分配给23个不同的vars),要求并且因此使用在dojo命名空间中可用的不同模块的TON。



示例:

  require(['dijit / form / ValidationTextBox','dijit / form / SimpleTextarea' dijit / form / CheckBox','dijit / Dialog','dijit / form / Form'])
require(['dojo / ready','dojo / parser','dojo / dom-style' dijit / registry','dojo / dom','dojo / _base / connect','dojo / dom-construct'],
函数(ready,parser,style,registry,dom,event, b $ b //...etc
}

这只是几个模块对于我正在做的一个页面,当然有一个更好的,不破产的未来重新发布访问这些方法的方式等等。我的意思是,我真的要导入一个全新的模块来使用 byId()?还有另一个连接事件?最重要的是,通过在函数参数列表中分配一个变量名称来创建所有的混乱,只是看起来像这样一个后台。



我以为也许 require()模块只在需要的时候,例如查询模块,但如果我需要它一次,那么机会就是分配给它的变量超出了范围,我需要把它放在一个 domReady! code>调用。



这是为什么我只能认为这是对dojo的不了解。



我真的看过和搜索并买了书(虽然是AMD之前的),但这个图书馆真的给了我一笔钱。



编辑例如

  require(['dijit / form / ValidationTextBox'])
require(['dojo / ready','dojo / parser','dojo / dom-style','dijit /注册表','dojo / dom','dojo / _base / connect','dojo / dom-construct'],function(ready,parser,style,registry,dom,event,construct){
/ * perform一些任务* /
var _name = new dijit.form.ValidationTextBox({
privcase:true,
tooltipPosition:['above','after']
},'name ')

/ *
假设我想在某些地方使用查询模块,例如
* /
require(['dojo / query' ,'dojo / dom-attr'],function(query,attr){
query('#list li')。forEach(function(li){
// do something with these
})
})
}

根据这种格式,是使用d与dojo工具包和第三方站点都有很多例子,那么IMHO绝对可以将所有必需的模块加载为第一个函数(ready,parser,style,registy)。 .. 会变得越来越长,并产生命名碰撞等问题。



点燃和 require( )在脚本生活中我需要的所有模块,对我来说似乎很愚蠢。话虽如此,我必须看一些包管理器脚本。但是,对于这个例子,如果我想在选择的地方使用查询模块,我将不得不将其加载到主要的 require()语句中。我明白为什么在一定程度上,但通用点语法命名空间有什么不好? dojo.whatever? dijit.findIt()?为什么加载模块,引用一个唯一的名字,通过关闭,blah blah?



我希望这是一个更容易的问题,但我希望是有道理的。



愤怒



给我一​​个新手,但这真的是真的开车我疯了我不是noob,当谈到Javascript(显然不是),但哇。我不能这个 出来!



这是我正在收集的。在adder.js中:

  define('adder',function(require,exports){
exports.addTen =函数(x){
返回x + 10
}
})



  require(['./ js / cg / adder.js']) 

...不遵循整齐的 require(['cg / adder'])格式,但无论如何。



然后,使用加法器应该是:

  console.log(adder.addTen(100))// 110 

最接近的是 console.log(adder)返回 3 。是的。 3 。否则,它是加法器未定义



为什么这么要这么困难?我正在使用我的noob卡,因为我真的不知道为什么这不是一起来。



谢谢你们。

解决方案

依赖数组格式:

  define([一个,b,c],函数(a,b,c){
});

确实令人烦恼,容易出错。将数组条目匹配到函数参数是一个真正的痛苦。



我更喜欢 require 格式(简体CommonJS Wrapper):

  define(function(require){
var a = require(a);
var b = require(b);
var c = require(c);
});

这样可以使您的线条简短,并允许您重新排列/删除/添加线条,而无需记住更改事情在两个地方。



后者的格式不适用于PS3和旧版Opera手机浏览器,但希望您不在乎。


对于为什么这样做而不是手动命名空间对象,@ peller的答案给出了一个很好的概述,为什么模块化是一件好事,而 https://stackoverflow.com/questions/9164326/whats-the-benefit-of-the-dojo-1-7-amd-framework/9165074#9165074\">我回答类似的问题谈论为什么AMD和模块系统作为实现模块化的一种方式是一件好事。



我将添加到@ peller的答案中的唯一的事情是扩展注意依赖关系使得更好的代码。如果你的模块需要太多的其他模块,那就是一个坏的标志!我们在我们的72K LOC JavaScript代码库中有一个松散的规则,一个模块应该是100行长,需要零到四个依赖关系。为我们服务。


I'm having a heckuva time transitioning to Dojo and the new AMD structure, and I'm really hoping someone can shed some light on the whole concept. I've been living on Google for the last few weeks trying to find information on not the usage, but the structure and design pattern trends in using this.

I find it strange that for a relatively complex javascript application, such as for a main page where Dijits need to be created and styled, DOM elements created, etc, that I need to require, and therefore use, a TON of different modules that were otherwise available in the dojo namespace before the AMD system (or, at least, not assigned to 23 different vars).

Example:

require(['dijit/form/ValidationTextBox', 'dijit/form/SimpleTextarea', 'dijit/form/CheckBox', 'dijit/Dialog', 'dijit/form/Form'])
require(['dojo/ready', 'dojo/parser', 'dojo/dom-style', 'dijit/registry', 'dojo/dom', 'dojo/_base/connect', 'dojo/dom-construct'], 
function(ready, parser, style, registry, dom, event, construct){
    //...etc
}

That's only a few of the modules for one of the pages I'm working on. Surely there's a better, non-breaking-in-future-releases way of accessing these methods, etc. I mean, do I really have to import an entirely new module to use byId()? And yet another to connect events? On top of that, all the clutter being created by having to assign a variable name in the functions argument list to cling to just seems like such a backstep.

I thought maybe you would require() the module only when needed, such as the query module, but if I need it more than once, then chances are the variable it's assigned to is out of scope, and I'd need to put it in a domReady! or ready call. reaalllly....??!

Which is why I can only assume it's my lack of understanding for dojo.

I really have looked and searched and bought books (albeit, a pre-AMD one), but this library is really giving me a run for my money. I appreciate light anyone can shed on this.

Edit for Example

require(['dijit/form/ValidationTextBox'])
require(['dojo/ready', 'dojo/parser', 'dojo/dom-style', 'dijit/registry', 'dojo/dom', 'dojo/_base/connect', 'dojo/dom-construct'], function(ready, parser, style, registry, dom, event, construct){
    /* perform some tasks */
    var _name = new dijit.form.ValidationTextBox({
        propercase : true,
        tooltipPosition : ['above', 'after']
    }, 'name')

    /*
    Let's say I want to use the query module in some places, i.e. here.
    */
    require(['dojo/query', 'dojo/dom-attr'], function(query, attr){
        query('#list li').forEach(function(li){
            // do something with these
        })
    })
}

Based off of this format, which is used with many examples both from the dojo toolkit folks as well as third party sites, it would be, IMHO, absolutely ridiculous to load all the required modules as the first function(ready, parser, style, registy... would get longer and longer, and create problems with naming collisions, etc.

Firing up and require()ing all the modules I would need during the life of the script just seems silly to me. That being said, I'd have to look at some of the "package manager" scripts. But for this example, if I wanted to use the query module in select places, I would either have to load it up with the rest in the main require() statement. I understand why to an extent, but what's so bad with generic dot-syntax namespaces? dojo.whatever? dijit.findIt()? Why load module, reference in a unique name, pass through closure, blah blah?

I wish this were an easier question to ask, but I hope that makes sense.

Exasperation

Call me a newb, but this is really.. really.. driving me mad. I'm no noob when it comes to Javascript (apparently not) but wow. I cannot figure this out!

Here's what I'm gathering. In adder.js:

define('adder', function(require, exports){
    exports.addTen = function(x){
        return x + 10
    }
})

In some master page or whatever:

require(['./js/cg/adder.js'])

...which doesn't follow the neat require(['cg/adder']) format but whatever. Not important right now.

Then, the use of adder should be:

console.log(adder.addTen(100)) // 110

The closest I got was console.log(adder) returning 3. Yep. 3. Otherwise, it's adder is not defined.

Why does this have to be so difficult? I'm using my noob card on this, cause I really have no idea why this isn't coming together.

Thanks guys.

解决方案

The dependency array format:

define(["a", "b", "c"], function (a, b, c) {
});

can indeed be annoying and error-prone. Matching up the array entries to function parameters is a real pain.

I prefer the require format ("Simplified CommonJS Wrapper"):

define(function (require) {
    var a = require("a");
    var b = require("b");
    var c = require("c");
});

This keeps your lines short and allows you to rearrange/delete/add lines without having to remember to change things in two places.

The latter format will not work on PS3 and older Opera mobile browsers, but hopefully you don't care.


As for why doing this instead of manually namespacing objects, @peller's answer gives a good overview of why modularity is a good thing, and my answer to a similar question talks about why AMD and module systems as a way of achieving modularity are a good thing.

The only thing I would add to @peller's answer is to expand on "paying attention to dependencies actually makes for much better code." If your module requires too many other modules, that's a bad sign! We have a loose rule in our 72K LOC JavaScript codebase that a module should be ~100 lines long and require between zero and four dependencies. It's served us well.

这篇关于Dojo require()和AMD(1.7)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆