【问题标题】:AngularJS: Good practice - where put the templates? (factory / directives)AngularJS:好的做法——把模板放在哪里? (工厂/指令)
【发布时间】:2015-09-11 12:12:10
【问题描述】:

我想知道哪种做法更好?

  1. 将模板放入指令中?
  2. 将模板放入工厂,将该工厂注入指令中并使用工厂的模板?

为了更好地理解:

示例 1:

angular.module('myApp').directive('myDirective1', function () {
    var myTemplate = '<div> 
                         //a looooot of HTML
                      </div>';

    return {
        template: myTemplate
    };
});

示例 2:

angular.module('myApp').directive('myDirective2', ['templateFactory', function (templateFactory) {

    return {
        template: templateFactory.myTemplate
    };
}]);


angular.module('myApp').factory('templateFactory', function () {
    var Template = '<div> 
                      //a looooot of HTML
                    </div>';
    return {
        myTemplate = Template
    }
});

假设我有例如 20 个指令,每个指令都有 它自己的模板 - 将所有模板放入工厂或离开 它们在指令中?

哪种方式更适合使用,更适合阅读, 对一切都更好?

为了阅读和更好地理解问题,我简化了这些指令,但在我的项目中,这些指令包含很多内容(控制器、作用域等)

【问题讨论】:

  • factory 在方法列表中将处于低位。其他方式有$templateCache、脚本标签模板、服务器文件等
  • 我建议保留指令外部的模板并使用templateUrl: /path/to/tmpl 稍后在template 字符串中编辑模板可能会变得很麻烦。正如上面@charlietfl 所说,我肯定会使用$templateCache

标签: angularjs templates factory directive


【解决方案1】:

我要做的是将模板放在资源下的单独文件中。

在指令中使用

angular.module('myApp').directive('myDirective1', function () {
    return {
        templateUrl: "path/to/the/template.html"
    };
});

如果您向应用程序之外的其他人提供指令,那么我会将它们放入指令中。像这样。

angular.module('myApp').directive('myDirective1', function () {
    return {
        template: "<div> ... </div>"
    };
});

【讨论】:

    【解决方案2】:

    我正在使用这种文件结构,我对此深信不疑;)

    js
     |- controllers
     |- directives
       |- ExampleDirective
         |- ExampleDirective.js
         |- ExampleDirective.html
       |- ...
     |- filters
     |- services
    

    然后将您的 指令templateUrl 一起使用,如下所示:

    angular.module('myApp').directive('ExampleDirective', function () {
        return {
            templateUrl: '[myPath]/ExampleDirective.html'
        };
    });
    

    【讨论】:

    • 结构使得模块化难以实现。尽管这是种子项目的启动方式,但很快就意识到它的可扩展性并不高
    • 嗯,我认为这取决于您的应用程序有多大(就模块种类而言)。如果您只有几个(逻辑划分的)模块,并且您的重点是控制器和模板逻辑,那么这可能是正确的选择。
    【解决方案3】:

    在与 AngularJS 斗争了 2 年后,我们来到了一个面向模块的结构,其中每个模块都可以是独立的组件,包括指令、服务、模板和测试。

    我们还定义了 2 个通用模块:Data LayerUI Library

    【讨论】:

    • 在尝试了不同的设置之后,我也得出了这个结论。使用自己的指令、服务、控制器等将组件分离到自己的文件夹中,并为所有组件使用共享/公共文件夹,该文件夹也有指令、服务、过滤器等文件夹。
    • 我喜欢模块化尝试,但你们如何为过滤器、服务等提供交叉访问?只需添加 2 个 messy 通用模块?
    • 这取决于您的项目架构。事实上,我所说的“数据层”可能很混乱
    猜你喜欢
    • 2011-12-13
    • 1970-01-01
    • 2020-12-27
    • 2011-06-10
    • 1970-01-01
    • 2012-11-28
    • 1970-01-01
    • 2010-11-14
    • 1970-01-01
    相关资源
    最近更新 更多