组件化时代:不同维度的组件侧重点有何不同?

@JimmyLv 2018-07-26 15:03:15发表于 JimmyLv/jimmylv.github.io ⭐️⭐️===博客素材===⭐️⭐️

其实问题中就已经点出,不同维度的组件应当有不同的侧重点。

Atomic Design 在电商领域的应用:

‎Atoms · ‎Molecules · ‎Organisms · Templates · Pages

原子 · 分子 · 组织/器官 · 模板 · 页面

Sites · Stores · Tenants · Platforms · Business Domain

站点 · 商店 · 租户/商户 · 平台 · 业务领域


从前到后,都存在多对1的关系。

组件化的目的无非两点:复用、自治

维度越低,其复用价值越大;维度越高,其自治价值越大。

低维度的组件,其UI层面的价值越大,也更加简单,配置项较少。

再引入时间的维度,从发展的角度看问题,那么:

如果说配置项越来越多,也就意味着组件所承载的业务含义越来越多。

业务来源于需求,导致的结果是数据的变化,从而映射到 View 层。

以上讨论维度,可以更多得限定于 原子 · 分子 层级。

高维度的组件,其Data流的价值更大,与此同时掺杂更多交互。

此处说的交互,不只是用户点击操作,还牵扯到时间、URL或API等数据变化。

而且,这个时候更应该从业务角度来讨论组件的复用和自治:

比如说「轮播」组件,其实它就应该算是一个 组织/器官,首先,当然需要考虑的是 UI 层面的交互功能,如轮播秒数、轮播次序、轮播效果等,但是更重要的是需要考虑数据的业务来源。

从电商领域的业务来说,就变得更加实际,要么是品牌宣传,要么是商品介绍,要么是优惠信息……

那么,考虑两个问题,即「业务组件」的数据获取和数据设置,即基于 CMS 的数据 getter 和 setter:

  • getter,这点很显然,以往给网站做轮播可能就是静态数据,当然更多可能就是从 API 交互而来。重点其实就在于 组织/器官 维度的组件应当是承担 API 交互职责的组件(Who),即知道何时(When)如何(How)从何处(Where)获取何种(What)数据。

由于我们在使用 GraphQL,我们的一个脑洞就是给这样的业务组件写 fragment,由于业务相对固定,这个 fragment 也就相对固定,就跟组件的 props 一样可以建立 model,跟 GraphQL 的 schema 相匹配组合;与此同时我们还可以在 page 层级将多个组件的 fragment 进行拼装,再统一请求后端 GraphQL,且只需一次 query 操作。

  • setter,这一部分其实就是在 CMS 上做文章,理想情况下,Templates + CMS Data = Pages 是成立的。Templates 是由‎ Organisms 所组成的,且 Organisms 所对应的 props 就是数据模型即 GraphQL schema,于是乎我们就可以有基于 Organisms schema 的 CMS 模型,无非就是每个组件的 prop 作为 key,propData 作为 value,从而自动生成类文档型数据库的 CMS。

并且,我们完全可以做到可见即可得的建站编辑器,左边为 Organisms 编辑框,右边为 空壳的初始化 Templates。只需要给每个 Organism 填充 CMS 数据,右边就能实时根据数据的变化重新渲染页面,即得到了真实用户所能看到的 Page。

再往后说,多个 Pages 共同组成了站点即 Site,而不带数据的 Site 其实就是一套皮肤,同一家商店可以有不同的皮肤,而不同商家其实也可以有多种皮肤。那么完全就可以做成模板市场,售卖一套一套的主题皮肤,而更进一步抽象的话,又可以变成模板开发平台,让开发者可以加入来独立开发主题/皮肤,跟平台分成从而达到指数级增长。

其实这里省略了 Pages 层面的讨论,在电商领域的官网业务当中,页面其实都是相对固定的,即首页、PLP、PDP等等。