使用RequireJS的Javascript命名空间,为什么?

时间:2012-12-17 20:22:01

标签: javascript jquery requirejs javascript-namespaces

我目前正面临关于javascript命名空间的争论,我需要一个社区意见。

情景: 负责这个项目的建筑师不知何故致力于RequireJS并且真的想要使用它。

我必须说应用程序是一个后台,作为一个向导进行布局,所以你可以在6页上来回使用一些复杂的业务逻辑来填充我在这里可以描述为进程请求的东西

好的,没有单页应用程序对这些问题没什么好看的。简单的后台Web应用程序,多页面,具有非常复杂的UI,其中每个页面都被请求到服务器,并且所有资源(css,javascript等)必须在页面加载时加载。

主要问题:了解我们正在讨论的应用类型,为什么要首先使用RequireJS?

第二个问题:为什么试图说服javacript中命名空间的最佳方法是使用RequireJS?我错过了什么吗?

我的意见: 对我来说根本没有任何意义。 在这里使用RequireJS很麻烦,因为没有按需加载资源,它们都是在页面加载时加载的(只是因为我们在页面加载时需要它们)。 我们至少需要支持IE8,Chrome,Firefox和Opera,而且我们在所有这些浏览器中加载资源时遇到了很多麻烦。通过Require。确保所有内容按预期加载已经有很多技巧。

对于命名空间来说,情况更糟。当然它再次起作用,对我来说似乎很麻烦,而且这件事实际上非常有限。

所以我错过了什么? 我需要第三(或第100)个意见。

  • 您如何看待这个?
  • 你用什么?
  • 为什么?

提前致谢

4 个答案:

答案 0 :(得分:4)

AMD加载器(RequireJS是一个)解决了不同的问题:

  • 适当的模块化,关注点分离
  • 没有全球污染
  • 没有姓名冲突
  • 按需加载或部署前优化
  • 取决于加载程序,用于解决高级问题的插件,例如本地化资源或加载时编译

我是这些加载器的忠实粉丝,发现除了非常小的单页应用程序外,它们都很有用。

答案 1 :(得分:3)

无论是否是“单页面应用程序”,在开发客户端JavaScript时,RequireJS可以帮助解决两个不容易的开发人员规则的问题:

生产与开发环境

现在,将JavaScript应用程序拆分为逻辑上类似于应用程序不同部分的文件是常识。它更容易调试和维护。但是在生产中,运送许多未压缩的文件对性能不利。因此,您将所有文件连接到一个文件中,缩小它(例如使用Google闭包编译器),然后将其作为单个gzip压缩文件发送。有许多不同的方法可以使用命令行工具(例如使用GruntJS)但没有像RequireJS这样的脚本加载器,您必须为两个不同的用例设置页面(将所有dev文件作为脚本标记引用)或单个production.js)自己。 RequireJS有一个NodeJS构建工具,可以为您完成所有这些工作。

<强>模块化

现在将代码保存在单独的文件中是很好的。但是由于JavaScript的本质和一切都是全局意味着你仍然可以遇到名称冲突等奇怪的事情。这就是命名空间派上用场的地方。但更好的选择是将所有内容包装到自己的函数中(引入自己的范围)。这就是为什么大多数JavaScript代码都是自动执行匿名函数的原因。如果此函数现在返回它想要公开的API,那么您将拥有Web模块。您可以单独从应用程序测试模块API,并在其他地方重复使用。

另请参阅RequireJS文档的Why Web Modules部分。

答案 2 :(得分:2)

在我个人看来,使用javascript模块系统几乎不是一个坏主意。 Requirejs也不是javascript模块唯一可能的加载器(但也许是最受欢迎的加载器)。一些替代品是LABjs或HeadJS。

这些装载机通常易于使用(一开始并没有太多麻烦),但在项目变得越来越大时可以提供很多帮助。它们可以避免在全局空间中命名冲突,还可以通过最小化/优化模块来支持部署步骤。最重要的事实是它们允许您编写更多模块化的JavaScript代码。

  • 你有一些实用功能吗?只需创建一个实用程序模块。
  • 您在所有页面上都需要一些功能吗?把它们放在一个共同的模块中。
  • 有些网页需要大量特定的JavaScript代码吗?为这些页面创建一个额外的模块,这样您就不必在其他页面上加载此代码。

答案 3 :(得分:0)

我目前使用$.extend来防止污染全球环境和命名冲突的解决方案。

文件系统树如下所示:

RootFolder
  +-> js
  global.js
  ...
   +-> views
       index.js
       page1.js
       page2.js
       ...
index.html
page1.html
page2.html

因此,它通常是一个包含所有应用程序共享代码的global.js文件,每页还有一个特定的。

对于命名空间我喜欢$ .extend所以在每个js文件中我都有类似的东西:

var app = app || {};  

/* only one document ready block per view if needed */
$(document).ready(function(){
    /* initialization code */
});

/* extend the app namespace with the Page1 code */
$.extend(app, {
    page1: {
        SayHi: function SayHi(name){
            alert('Hi ' + name);
        }
    }
});

因此,您可以通过以下方式访问您的代码:

app.page1.SayHi("Alex");

使用这种技术:

  • 完全控制您的代码。没有神奇的资源加载和花哨的东西,你没有完全控制。
  • 没有全球环境污染
  • 没有命名冲突
  • 命名空间树可以根据您的意愿深入,您是自己复杂性的拥有者。
  • 您可以拥有几个实际上对同一命名空间级别有贡献的js文件。这对辅助工具特别有用。
  • 根据您在网页上添加的javascript文件,您可以拥有更大或更小的应用程序命名空间。

<强>结论:

Web环境非常简单,我们不应该使它复杂化。

我没有打过RequireJS,不要误会我的意思。它实现了它的意义(其本质上是纯粹的资源延迟加载)。其他所有东西都是包装附带的东西,但也可以更清洁透明的方式使用。

因此,如果我不需要主要功能,则无需使用它。

干杯!