产品特点
1 多角色产品,分为广告主和供应商,通过订单流程管理双方的交易行为。这就意味组件的状态是多变,这里多变主要是因为一下两个点影响
一:角色,每个组件不同的角色会有不同行为, 和后台交互的 API 也是不一样的 w
二:订单状态,每个组件在不同的订单状态会有不同行为
2 探索性产品,产品的方案都是摸索实践中产生,没有成型产品可以借鉴,这就意味着订单流程随时都可能变化,随时都要对老数据展示进行修复处理。(我们订单流程大的变化有过 3 次,每一次都必须兼容老数据的处理,头大..)
前端架构
架构的目的是管理复杂度,将复杂问题分为治之,有效管理,方便后续的开发与迭代
1 通过路由切换页面级粒度的功能模块
2 同一页面内的模块再划分
一: 纵向 通过业务功能(可根据试图模块判断)划分
二: 横向:通过 model-view-controller 三种不同职能划分
这里根据我们业务的特点:1 组件的 UI 状态显示逻辑比较复杂,所以我们将组件的显示和数据分离, 将组件分为容器型组件和展示型组件。容器组件负责为展示型组件或者其他容器组件提供数据和行为,尽量避免在其中做一些界面渲染相关的事情。展示型组件独立于应用的其它部分内容,不关心数据的加载和变更,保持职责单一,仅做视图呈现和最基本交互行为,通过 props 接收数据和回调函数输出结果,保证接收的数据为组件数据依赖的最小集
通过沉淀可复用的通用业务组件提供 admin 端,广告主端 供应商端复用。2 由于面临着后续修复数据的问题。我们尽量收敛数据,所以尽量将 API 的控制的调用封装在第一层的业务功能组件上。保证及时修改到所有。