更新5/24/2018: 我们现在已经从我最初的帖子中 + 3版本的 Angular,但仍然没有最终可行的解决方案。Lars Meijdam (@LarsMeijdam)提出了一个有趣的方法,当然值得一看。(由于专有问题,他不得不暂时删除他最初发布样本的 GitHub 存储库。但是,如果你想要一份拷贝,你可以直接给他发信息。更多信息请参见下面的评论。)
角度6最近的架构变化确实让我们离解决方案更近了一步。此外,角元素(https://angular.io/guide/elements)提供了一些组件功能——尽管不是我最初在这篇文章中描述的那样。
如果有任何人从惊人的角团队碰巧遇到这一点,请注意,似乎有很多其他人谁也对这一功能非常感兴趣。对于积压的工作,这可能是值得考虑的。
我想在 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
之后) ,而且这个足迹还在继续缩小TypeScript
和 Observables
)配合得很好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
应用程序并不总是最容易调试的。不良插件的应用可能导致非常不愉快的经验。我目前还不知道一种优雅地处理不良插件的机制。