2018年5月24日更新:根据我的原始帖子,我们现在是Angular的+3版本,并且仍然没有最终可行的解决方案。Lars Meijdam(@LarsMeijdam)提出了一种有趣的方法,当然值得一看。(由于专有问题,他不得不临时删除他最初发布其示例的GitHub存储库。但是,如果您想要复制它,可以直接向他发送消息。更多信息,请参见下面的评论。)
Angular 6最近的架构更改确实使我们更接近解决方案。此外,Angular Elements(https://angular.io/guide/elements)提供了一些组件功能-尽管与我在本文中最初描述的功能不尽相同。
如果来自惊人的Angular团队的任何人碰巧遇到此问题,请注意,似乎还有很多其他人对此功能也非常感兴趣。积压的订单可能值得考虑。
我想实现在一个可插拔(插件)的框架Angular 2
,Angular 4
,Angular 5
,或Angular 6
应用程序。
(开发这个可插入框架的特定用例是,我需要开发一个小型的内容管理系统。由于此处未详细说明的许多原因,Angular 2/4/5/6
它非常适合该系统的大多数需求。)
我所说的可插拔框架(或插件体系结构)是指一种系统,该系统允许第三方开发人员通过使用可插拔组件来创建或扩展主应用程序的功能,而无需直接访问或了解主应用程序的源代码。或内部运作。
(关于“ 没有直接访问或不知道应用程序的源代码或内部工作原理的措辞”是一个核心目标。)
可插入框架的示例包括常见的内容管理系统,例如WordPress
或Drupal
。
理想的情况(与Drupal一样)将是能够简单地将这些可插入组件(或插件)放入文件夹中,让应用程序自动检测或发现它们,并使它们神奇地“工作”。以某种可热插拔的方式发生这种情况,这意味着在应用程序运行时将是最佳选择。
我目前正在尝试(在您的帮助下)确定以下五个问题的答案。
- 实用性:
Angular 2/4/5/6
应用程序的插件框架甚至实用吗?(直到现在,我还没有找到使用来创建真正可插拔框架的任何实用方法Angular2/4/5/6
。) - 预期的挑战:在为
Angular 2/4/5/6
应用程序实现插件框架时可能遇到什么挑战? - 实施策略:可以为实施
Angular 2/4/5/6
应用程序的插件框架采用哪些特定技术或策略? - 最佳实践:为
Angular 2/4/5/6
应用程序实现插件系统的最佳实践是什么? - 替代技术: 如果一个插件框架是不实际在
Angular 2/4/5/6
应用,哪些相对相当于技术(例如React
)可能是适合现代高反应性的Web应用程序?
通常,Angular 2/4/5/6
非常需要使用,因为:
- 它自然是非常快-如此之快。
- 它消耗的带宽很小(在初始加载之后)
- 它的足迹相对较小(在
AOT
和之后tree shaking
),并且足迹不断缩小 - 它功能强大,并且Angular团队和社区正在持续快速发展其生态系统
- 它与许多最佳和最新的Web技术(例如
TypeScript
和Observables
- Angular 5现在支持服务人员(https://medium.com/@webmaxru/a-new-angular-service-worker-creating-automatic-progressive-web-apps-part-1-theory-37d7d7647cc7)
- 得到的支持
Google
,将来可能会得到支持和增强。
我非常想将其Angular 2/4/5/6
用于当前项目。如果我能够使用Angular 2/4/5/6
,我也将使用Angular-CLI
并且可能Angular Universal
(用于服务器端渲染)。
到目前为止,这是我对上述问题的看法。请查看并提供您的反馈和启示。
Angular 2/4/5/6
应用会使用程序包-但这不一定与允许应用程序内的插件相同。Drupal
可以通过将plugin文件夹放到公共模块目录中来实质上添加其他系统(例如)中的插件,系统会在该目录中自动将其“拾取”。在中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
应用程序中,尤其是预编译的应用程序中,一条错误或冲突的代码可能会破坏整个应用程序。Angular 2/4/5/6
应用程序并非总是最容易调试的。行为不当的插件的应用可能会导致非常不愉快的体验。我目前不了解正常处理不良行为插件的机制。