【问题标题】:How should I split up my js-files to be easy to maintain? [closed]我应该如何拆分我的 js 文件以便于维护? [关闭]
【发布时间】:2014-08-12 21:14:46
【问题描述】:

尝试以这种方式分离 javascript 时我会怎么做:

这是我的问题: 我有一个巨大的 js 文件,在这个文件中我有用于产品过滤器的函数。我想在多个位置使用这些“product-filter-functions”,但我不想包含一个巨大的 js 文件。

我想要类似的东西:

huge.js          // merely everything that has something to do with products
productfilter.js // inclusion of productfilter-functions */

当我只想使用产品过滤器功能时,我显然只包含 productfilter.js

productfilter.js 将具有如下功能:

function getSelectedGender() {    
...
}

function getSelectedColors() {
....
}

function getSelectedBrandId() {
....
}

如果我在 huge.js 和 productfilter.js 中有一个同名的函数,我不知道会触发其中的哪个函数。 (我试过了,看起来有点随机)

我当然可以根据我所在网站的哪个部分编写新功能(具有相同类型的功能),但我认为这将是糟糕的设计并且很难维护。

我在这里寻找指针..

【问题讨论】:

  • 看看 browserify:browserify.org
  • 听起来你想要名称间距。
  • 在构建站点时,我发现在站点范围内加载两个脚本效果最好。一个是每个页面都需要的东西(jq、bs 等)。第二个根据加载它的部分(验证器、媒体库等)的需要而有所不同。有时第二个脚本使用 require 加载更多,有时它由构建过程组装。如果某个部分中的单个页面需要更多,我会为该页面加载第三个脚本。

标签: javascript include


【解决方案1】:

您可以尝试对 JS 进行命名空间,以便保留函数名称,例如:

huge.functionName()
product.functionName()

而不是

functionName()
functionName()

【讨论】:

  • 我想这就是我需要的。不过,我将不得不阅读如何在 js 中实现命名空间。谢谢!
  • @bestprogrammerintheworld:命名空间基本上是将所有方法包装在命名对象文字中。这是an easy way 来做的。
【解决方案2】:

我是RequireJS 的粉丝,因为我以一种整洁的方式开发具有完善依赖关系的模块。在building/optimizing 最终分发 JS 文件(如果选择)期间,只会包含必需/请求的模块。因此代码可以专注于依赖关系和逻辑分组,而构建工具包含相关模块。更大的或外部的模块(例如 jQuery)也可以通过手动脚本包含或通过单独的异步“AMD”获取加载来保持外部和源代码。

然而,即使 没有 RequireJS/AMD,模块也可以用来在不同的命名空间中保持 JavaScript 代码的整洁。我指的是"UMD" patterns,适应了当前的需要。以这个带有 jQ​​uery 依赖的“AMD Web Global”模式为例:

(function (root, factory) {
    // The if-branch can be eliminated if /never/ using RequireJS/AMD,
    // but leaving it in keeps this pattern compatible with such loaders.
    if (typeof define === 'function' && define.amd) {
        define(['jQuery'], function (jQuery) {
            return (root.foo = factory(jQuery));
        });
    } else {
        root.foo = factory(root.jQuery);
    }
}(this, function ($) {
    function bar() {    
        // ...
    }
    return {
        bar: bar
    };
}));

以后创建的“命名空间”就可以使用了:

foo.bar()

这种模式在有/没有 AMD 的情况下都可以工作(例如 RequireJS),并且在组合后也可以工作,如果选择了这样的话。如果没有进行基于工具的组合,则可以使用标准的多脚本包含来加载依赖项(缺点是必须手动处理依赖项顺序)。

使用此类模块模式的另一个好处是更改为上下文正确的工厂构建器是微不足道的:

// In the module, exported as window.OptionManager using the above pattern
}(this, function ($) {
    function OptionManager (form) {
        this.getSelectedGender = function () {
            return $(form).find(".gender").val();
        };
    }
    return OptionManager;
}));

及用法:

var options = new OptionManager($("#optionForm"));
options.getSelectedGender();

由于代码的清晰区分,以后组合不同的模块、维护依赖关系(视情况而定)是微不足道的——单独的文件、单个整体文件、多个组合文件——同时保持代码库的可维护性。

【讨论】:

  • 我认为这是一个很好的答案,但在我的具体情况下,我认为命名空间是要走的路(我可能错了。时间会证明一切)。但我会将此页面添加为书签(是的,真的!),所以我可以回到这里进行未来的项目
猜你喜欢
  • 1970-01-01
  • 2017-05-15
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-03-02
  • 1970-01-01
相关资源
最近更新 更多