Angularjs 在配置块外部使用角度编译器Provider

我试图在运行中创建指令，事实上我做到了，但是非常粗糙

这是我的第一个方法：

function create(myDir) {
   angular.module("app").directive(myDir.name, function() {
   return {
     template:myDir.template
   };
  });
}

它不起作用，因为在应用程序启动后无法注册指令

根据这篇文章：

我发现我可以使用compileProvider来完成这项工作，但由于compileProvider在config块之外不可用，您需要将其推出，所以我做了：

var provider = {};
angular.module("app",[]);        

angular.module('app')
.config(function ($compileProvider) {
    //It feels hacky to me too.
    angular.copy($compileProvider, provider);
 });
....

function create(myDir) {
    provider.directive.apply(null, [myDir.name, function () { 
        return { template: myDir.template } }]);
    render(myDir); //This render a new instance of my new directive
}

---

令人惊讶的是，它奏效了。但我不想入侵编译器Provider，因为我使用它的方式与预期不同，我很想知道在应用程序启动后是否可以正确使用编译器Provider。

有一个可以注入

config

块的依赖项列表（这些是内置的

$provide

，

$injector

和所有服务提供商）以及可以注入到其他任何地方的依赖项列表（服务实例和良好的旧

$injector

）。正如您所看到的，

常量所做的一切就是

在
config
之外使用提供程序的常见方法是

app.config(function ($provide, $compileProvider) {
  $provide.constant('$compileProvider', $compileProvider);
});

创建您自己的提供程序并向其中注入$compileProvider，然后让新的提供程序发布使用它的服务。您还可以检查哪个提供程序完全符合您的要求。这两条评论都很好，但我仍然担心将compileProvider从其范围中移除这一事实此解决方案非常适合，而且非常优雅，但是我仍然担心提供者的使用超出了它的范围，正如你所说的，有一些“依赖项”只能注入配置块中，如果它们这样做了，那应该是有原因的，我觉得我在使用它来适应我的解决方案，但不确定这是否是一种好的方式有原因。它需要有一个线索，在特定的供应商发生了什么。提供程序被用作创建服务实例的封装外形，对提供程序所做的一些更改不会影响实例，有些更改会影响实例。关于$compileProvider，可以随时安全地注册新服务（指令也是服务）。它可能需要在文档中重新编译这些指令（若有）（它们最初并没有编译，因为它们不存在）。但这是完全可以做的，例如路由器视图。