在Angular 2,4,5,6中实现插件架构/插件系统/可插拔框架

Question

2018年5月24日更新：我们现在有3个版本的Angular从我原来的帖子，仍然没有一个最终可行的解决方案。Lars Meijdam（@LarsMeijdam）提出了一个有趣的方法，当然值得一看。（由于专有问题，他不得不临时删除他最初发布样本的GitHub存储库。但是，如果您想要副本，您可以直接给他发消息。有关更多信息，请参阅下面的评论。）

Angular 6最近的架构变化确实让我们更接近解决方案。此外，Angular Elements（https://angular.io/guide/elements）提供了一些组件功能，尽管与我最初在这篇文章中描述的不太一样。

如果来自惊人的Angular团队的任何人碰巧遇到这个问题，请注意，似乎还有许多其他人也对这个功能非常感兴趣。对于积压工作来说，这很值得考虑。

我想在angular2、angular4、angular5或angular6应用程序中实现一个可插入（插件）框架。

（我开发这个可插拔框架的具体用例是，我需要开发一个微型内容管理系统。由于这里不必详细阐述的一些原因，Angular 2/4/5/6几乎完全适合该系统的大多数需求。）

我所说的可插拔框架（或插件体系结构）是指允许第三方开发人员通过使用可插拔组件来创建或扩展主应用程序功能的系统，而无需直接访问或了解主应用程序的源代码或内部工作。

（关于“不直接访问或了解应用程序的源代码或内部工作原理”的措辞是一个核心目标。）

可插拔框架的示例包括常见的内容管理系统，如WordPress或Drupal。

理想的情况（与Drupal一样）是能够将这些可插入组件（或插件）放入文件夹中，让应用程序自动检测或发现它们，并让它们神奇地“工作”以某种热插拔方式实现这一点，这意味着在应用程序运行时，将是最佳选择。

我目前正试图（在您的帮助下）确定以下五个问题的答案。

1. 实用性：用于Angular 2/4/5/6应用程序的插件框架是否实用？（到目前为止，我还没有找到任何实用的方法来使用Angular2/4/5/6创建一个真正的可插入框架）

通常，使用角度2/4/5/6是非常可取的，因为：

• 它自然是非常快的——非常快

我非常想在我当前的项目中使用Angular 2/4/5/6。如果我能够使用Angular 2/4/5/6，我还将使用Angulal-CLI和可能的Angular Universal（用于服务器端渲染）。

以下是我对上述问题的看法。请回顾并提供您的反馈和启示。

>

Angular 2/4/5/6应用程序使用包--但这并不一定与在应用程序中允许插件相同。其他系统中的插件（例如Drupal）基本上可以通过将插件文件夹放入一个公共模块目录中来添加，在该目录中系统会自动“拾取”插件。在Angular 2/4/5/6中，一个包（可能是插件）通常通过npm安装，添加到package.json中，然后手动导入到应用程序中app.module。这比删除文件夹并让系统自动检测包的Drupal方法复杂得多。安装插件越复杂，人们使用它们的可能性就越小。如果有一种方法让Angular 2/4/5/6自动检测和安装插件，那就更好了。我非常有兴趣找到一种方法，允许非开发人员安装Angular 2/4/5/6应用程序，并安装任何选择的插件，而无需了解应用程序的所有架构。

通常，提供可插拔体系结构的好处之一是，第三方开发人员很容易扩展系统的功能。显然，这些开发人员并不熟悉他们所插入的应用程序的所有复杂代码。一旦开发了插件，其他技术性更低的用户可以简单地安装应用程序和任何选定的插件。然而，Angular 2/4/5/6相对复杂，学习曲线非常长。使事情进一步复杂化的是，大多数生产Angular 2/4/5/6应用程序还利用Angular CLI、Angular Universal和WebPack。实现插件的人可能至少需要具备一些关于所有这些如何结合的基本知识，以及对TypeScript的丰富工作知识和对NodeJS的合理熟悉。知识需求是否如此极端，以至于没有第三方愿意开发插件？

大多数插件可能有一些服务器端组件（例如，用于存储/检索插件相关数据）以及一些客户端输出。Angular 2/4/5特别（强烈）阻止开发人员在运行时注入自己的模板-因为这构成了一个严重的安全隐患。为了处理插件可能容纳的许多类型的输出（例如图形的显示），似乎允许用户创建以一种形式注入响应流的内容是必要的。我想知道如何在不象征性地粉碎Angular 2/4/5/6的安全机制的情况下满足这种需求。

大多数生产Angular 2/4/5/6应用程序使用Ahead of Time（AOT）编译进行预编译。（也许一切都应该如此。）我不确定如何将插件添加到（或与）预编译的应用程序集成。最好的方案是将插件与主应用程序分开编译。然而，我不确定如何使这项工作。一个回退可能是使用任何包含的插件重新编译整个应用程序，但对于一个只想将应用程序（在他自己的服务器上）与任何选定的插件一起安装的管理用户来说，这让事情变得有点复杂。

在Angular 2/4/5/6应用程序中，尤其是在预编译的应用程序中，一段错误或冲突的代码可能会破坏整个应用程序<代码>角度2/4/5/6应用程序并不总是最容易调试的。应用行为不端的插件可能会导致非常不愉快的体验。我目前还不知道有一种机制可以优雅地处理行为不端的插件。