# 多框架支持
前端框架种类繁多，Raptor 又是如何支持各种技术栈团队的呢？我们以 Vue、React 为例。
组件化和可视化是分不开的，想要支持 Vue、React 组件需要直面一个问题：如何在可视化编辑页保证可视化平台本身和业务组件不会存在框架冲突
显然，考虑在「A」框架内兼容运行「B」框架的想法是不长远的，不仅前端框架种类多，框架版本更新导致 API 变动也会使得中台疲于兼容处理。
从长远考虑，用 Iframe 将「编辑页」和「预览区」隔离是一劳永逸的。当然，采用 Iframe 隔离还有其他方面的考量。分析其优劣式可得：
# 优点：
- Iframe 内的 fixed 定位天然支持。
- Iframe 内独立的 window 环境，不与可视化编辑页共享从而杜绝隐患。
- Iframe 内组件所用技术栈与可视化操作平台技术栈无关，使得平台支持各种前端框架更加容易。
- Iframe 页地址为业务方域名 URL，可共享其业务登录态。
- 重构（设计稿+手撸代码）开发的页面，亦可放到中台再编辑，享用已沉淀的插件。（理解稍难）
# 缺点：
- 可视化拖拽的交互实现比较麻烦。
- 各业务需要存档一份
预览页 HTLM文件，对外提供业务域名访问的 URL。
# 编辑页预览数据流
单向流动原则，编辑页通过postMessage渠道下发数据到预览页。
# 多框架的预览实现
Raptor 编辑页中的预览页和独立窗口的预览页实则为同一个页面。当以 Iframe 内嵌在编辑页时，通过 postMessage 渠道获取页面数据， 当为独立窗口时，通过 URL 参数的页面 ID 向中台查询该页面数据。
从上图的数据流来看，可以发现即便框架不同，但其预览页内存在不少相同的逻辑（比如获取页面数据，treeData 解析），
我们可以提炼出其公共部分，这便是 Raptor 高效率兼容多框架的主要原因。
TIP
组件通信实现在 render-core 中，组件嵌套则在调用框架 Render API 过程中根据 treeData 结构实现。