项目实践总结

29次阅读

共计 659 个字符,预计需要花费 2 分钟才能阅读完成。

产品特点

1 多角色产品,分为广告主和供应商,通过订单流程管理双方的交易行为。这就意味组件的状态是多变,这里多变主要是因为一下两个点影响

  一:角色,每个组件不同的角色会有不同行为, 和后台交互的 API 也是不一样的 w
  二:订单状态,每个组件在不同的订单状态会有不同行为
 

2 探索性产品,产品的方案都是摸索实践中产生,没有成型产品可以借鉴,这就意味着订单流程随时都可能变化,随时都要对老数据展示进行修复处理。(我们订单流程大的变化有过 3 次,每一次都必须兼容老数据的处理,头大..)

前端架构

 架构的目的是管理复杂度,将复杂问题分为治之,有效管理,方便后续的开发与迭代
 
 
 1 通过路由切换页面级粒度的功能模块
 

 2  同一页面内的模块再划分
     
    一: 纵向 通过业务功能(可根据试图模块判断)划分
    二: 横向:通过 model-view-controller 三种不同职能划分
    
    这里根据我们业务的特点:1 组件的 UI 状态显示逻辑比较复杂,所以我们将组件的显示和数据分离, 将组件分为容器型组件和展示型组件。容器组件负责为展示型组件或者其他容器组件提供数据和行为,尽量避免在其中做一些界面渲染相关的事情。展示型组件独立于应用的其它部分内容,不关心数据的加载和变更,保持职责单一,仅做视图呈现和最基本交互行为,通过 props 接收数据和回调函数输出结果,保证接收的数据为组件数据依赖的最小集
    通过沉淀可复用的通用业务组件提供 admin 端,广告主端 供应商端复用。2 由于面临着后续修复数据的问题。我们尽量收敛数据,所以尽量将 API 的控制的调用封装在第一层的业务功能组件上。保证及时修改到所有。

正文完
 0