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
基本上可以通过将插件文件夹拖放到系统自动“拾取”的公共模块目录中来添加其他系统中的插件(例如)。在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
应用程序并不总是最容易调试的。应用不良插件可能会导致非常不愉快的体验。我目前不知道有一种机制可以优雅地处理行为不端的插件。