# 组件与素材库
Raptor 以组件为基础单元，每个组件都是独立的个体，准确来说，组件的每个版本都是独立的个体。
这与常见的组件化中台提出的组件库或素材库（后续统一称素材库）不同，这类中台只能做到素材库为基础单元，无法细分组件（其组件只能相对于本素材库而言）。
组件与素材库 2 种不同的设计思想各有特点，其中以下面几点最为特别。
# 跨组复用
上图左侧，红、蓝 2 个业务组有使用到相同功能的组件 A，但由于素材库的隔离，他们只能各自维护着该功能的组件。
上图右侧，所有组件都沉淀在组件市场，红、蓝 2 组按业务需要注册相应组件，复用组件 C，大大提高组件复用率，减少开发工作量。
# 版本管理
上图左侧，由于素材库是整体迭代升级的，过程中组件 A可能被修改，而此前使用组件 A的页面由于其组件 A的配置数据（主要是结构）比较旧，
在新的组件 A逻辑下可能触发异常，从而影响页面稳定。如果升级之后发现问题，素材库回滚之前的版本，但由于已有页面使用到新增的组件 C，
回滚操作将导致使用组件 C的页面异常，这更是灾难性的，因为这个缘由，素材库方案的设计可以说是没有版本管理，因为管起来的风险太高，
干脆不管了。
上图右侧，由于组件按版本迭代，组件的每个版本都是独立的个体，组件在加入页面一刻起，页面就固定了使用组件的某个版本，不会随组件的版本迭代而变动。 且组件某版本一旦发布，该版本不能被覆盖或删除。页面将永远是用户配置完所体验到的那样。
# 预览页性能
当我们在编辑页面时，编辑过程实时预览是可视化的基本体验要求，除了编辑页中需要实时预览之外，也需要独立的预览页供用户访问。
也正是由于实时预览的要求，素材库方案的中台往往在预览页加载完整的素材库，但一个页面使用的组件才 10 几个，业务的素材库
包含 200 个组件都是极为正常的，这导致预览页的性能随着业务体量增大（组件增多）而越发糟糕。
素材库方案想在预览页做按需加载是可以做到的，需要实时根据页面挑选的组件剔除掉未使用的组件，但基于现有工具链做到的实时效果不理想。
而以组件为基础单位的方案，由于组件的每个版本都是独立的个体，可以较轻松的实现在为页面添加组件的时机在现场异步加载组件，
这个异步过程产生的时间空隙基本等同于一个组件包加载的时间（100ms以内），人是无法感知到这个差异的。
TIP
预览页性能问题的存在，使得素材库方案的中台存在上限，而以组件为基础单元的方案可认为不存在上限，小到为公司服务，大到供全球服务。
# 复杂度
素材库方案相比于组件方案优点在于简单，主要体现在：
- 中台开发简单。预览页直接加载业务组完整素材库，不用处理按需加载问题，更不用处理组件的依赖包问题。
发布（编译）时因为
素材库的依赖都写在package.json中，能很好的借助当前打包生态。 - 业务接入简单。以
组件为单元的方式，业务组需要为预览页配置AMD模块路径以支持按需加载， 而素材库方式不存在该要求。