构建CoffeesSript浏览器应用程序——命名空间和作用域问题

Building CoffeesSript browser applications - namespace and scope issues

本文关键字：作用域 问题 命名空间 构建 浏览器 应用程序 CoffeesSript      更新时间：2023-09-26

我是CoffeeScript的新手，我试图获得管理和构建将在浏览器中运行的复杂应用程序的最佳方式的感觉。所以，我试图确定什么是最好的方式来构建我的代码和构建它;考虑范围、测试、可扩展性、清晰度和性能问题。

这里建议的一个简单的解决方案(https://github.com/jashkenas/coffee-script/wiki/%5BHowTo%5D-Compiling-and-Setting-Up-Build-Tools)似乎是单独维护所有的文件/类-并使用Cakefile将所有文件连接到一个单一的咖啡文件并编译它。就确保所有内容都在相同范围内结束而言，这似乎是可行的。它似乎也使部署变得简单。而且，它可以自动化，这很好。但是感觉它不是最优雅或可扩展的解决方案。

另一种方法似乎是这种生成名称空间的函数式方法(https://github.com/jashkenas/coffee-script/wiki/Easy-modules-with-CoffeeScript)。这似乎是一个聪明的解决方案。我对它进行了测试，它可以工作，但我想知道是否有性能或其他缺点。它似乎也可以与上述方法相结合。

另一个选项似乎是分配/导出类和函数到窗口对象。听起来这是一种相当标准的方法，但我很好奇这是否真的是最好的方法。

我尝试使用Spine，因为它似乎可以解决这些问题，但遇到了问题，使其启动和运行(无法安装Spine)。app或hem)，我怀疑它使用了上述一种或多种技术。如果javascript tmvc或backbone能解决这些问题，我会很感兴趣——我也会考虑它们。

谢谢你的想法

另一个选项似乎是分配/导出类和函数到窗口对象。听起来这是一种相当标准的方法，但我很好奇这是否真的是最好的方法。

我认为是。看看这个wiki页面的历史，主张在编译之前将.coffee文件连接起来的人是Stan Angeloff，早在2010年8月，在链轮2 (Rails 3.1的一部分)这样的工具出现之前。这绝对不是标准的方法。

你不希望多个.coffee文件共享同一个作用域。这违背了语言的设计，它将每个文件包装在作用域包装器中是有原因的。必须将全局变量附加到window以使其成为全局变量，从而使您避免犯javascript最常见的错误之一。

是的，helper复制可能会导致一些效率低下，并且有一个关于在编译期间禁用helper输出的选项的公开讨论。但是影响很小，因为helper只占代码的一小部分。

如果javascriptMVC或backbone能解决这些问题，我会很感兴趣

JavaScript MVC和BackBone不做任何关于作用域问题，除非它们导致您将数据存储在全局对象而不是局部变量中。我不确定你所说的《Spine》"似乎能够解决这些问题"是什么意思;如果你能再发一个更具体的问题，我会很感激的。

如果您更喜欢node.js模块系统，这将在浏览器中提供相同的功能:https://github.com/substack/node-browserify

File foo.coffee:

module.exports = class Foo
  ...

File bar.coffee:

Foo = require './foo'
# do stuff
相关文章：