能否使用Angular Elements构建复杂Web Components适配jQuery老旧项目

完全可以通过 Angular Elements 封装复杂多组件的Angular业务模块为标准Web Components，在jQuery旧应用中直接使用，这也是这类渐进式技术栈升级场景的常用方案。

适配优势 #

• 编译后的Angular Elements是符合W3C Custom Elements规范的原生组件，和普通DOM元素使用方式完全一致，不需要在旧应用中引入额外的Angular宿主依赖，直接通过自定义标签插入到页面对应位置即可。
• 内部可完整保留Angular的技术栈能力：不管是多级嵌套组件、路由（可使用内存路由或hash路由避免和旧应用路由冲突）、NgRx/RxJS状态管理、第三方Angular组件库引入，都可以正常运行，对外只暴露单个自定义标签入口，内部逻辑完全封装不对外暴露。
• 新旧应用通信成本极低：旧应用可以直接通过jQuery操作自定义标签的属性传参，也可以监听自定义标签抛出的原生DOM事件接收组件内部的通知，不需要额外的通信协议适配。
• 运行时完全隔离：Angular的运行时会被打包到组件产物中，和旧应用的jQuery、其他第三方依赖的全局作用域完全隔离，不会出现变量冲突、原型链污染等问题。

落地注意事项 #

• 打包时按需引入polyfill：如果你的旧应用需要兼容IE11这类低版本浏览器，按需打入Web Components相关polyfill即可，同时注意关闭polyfill的全局注入开关，避免和旧应用已有的polyfill冲突。
• 开启Shadow DOM隔离样式：建议在封装组件时开启Shadow DOM，避免Angular组件的样式和旧应用的全局样式互相污染。
• 自定义标签命名必须符合规范：标签名需要包含至少一个短横线，例如<app-contract-manage>，避免和原生HTML标签重名。

替代方案参考 #

如果你的新增模块是独立的页面级功能，也可以根据场景选择以下方案：

• iframe嵌入：将Angular应用独立打包后通过iframe插入旧应用，通过postMessage完成跨上下文通信。优势是完全隔离，开发不需要考虑新旧技术栈的兼容问题；劣势是需要额外处理iframe高度自适应、弹窗跨iframe展示等问题。
• 轻量微前端挂载：如果后续还有其他技术栈的新增模块需求，可以用single-spa这类轻量微前端框架统一管理子应用，不过对于仅新增单个Angular模块的场景，引入微前端的研发成本远高于直接使用Angular Elements。

内容的提问来源于stack exchange，提问作者user2123523