“整洁架构”和商家前端的重构之路

  

• 可以减弱对ui框架的依赖
  

  

• 代码风格可以更加统一
  

  

• 可以集成自动化测试用例
  

  

• 与框架无关：无论是前端代码还是服务端代码，其逻辑本身都应该是独立的，不应该依赖于某一个第三方框架或工具库。一套独立的代码可以把第三方框架等作为工具使用。  
  
• 可测试：代码中的业务逻辑可以在不依赖ui、数据库、服务器的情况下进行测试  
  
• 和ui无关：代码中的业务逻辑不应该和ui做强绑定。比如把一个web应用切换成桌面应用，业务逻辑不应该受到影响。  
  
• 和数据库无关：无论数据库用的是mysql还是mongodb，无论其怎么变，都不该影响到业务逻辑。  
  
• 和外部服务无关：无论外部服务怎么变，都不影响到使用该服务的业务逻辑。
  

interface IRawOrder {
  amount: number
  barCode: string
  orderNo: string
  orderType: string
  skuId: number
  deliveryTime: number
  orderTime: number
  productImg: string
  status: number
}
export default function buildMakeOrder({
  formatTimestamp,
  formatImageUrl,
}: {
  formatTimestamp: (timestamp: number, format?: string) => string
  formatImageUrl: (
  image: string,
  config?: { width: number; height: number },
  ) => string
}) {
  return function makeOrder(raw?: IRawOrder) {
  if (!raw || !raw.orderNo) {
     Monitor.warn('脏数据')
     return null;
  }
  return {
    amount: raw.amount,
    barCode: raw.barCode,
    orderNo: raw.orderNo,
    orderType: raw.orderType,
    skuId: raw.skuId,
    status: raw.status,
    statusDescription: selectStatusDescription(raw.status),
    deliveryTime: formatTimestamp(raw.deliveryTime),
    orderTime: formatTimestamp(raw.orderTime),
    productImg: formatImageUrl(raw.productImg),
  }
  }
}
function selectStatusDescription(status: number): string {
  switch (status) {
  case 0:
    return '待支付'
  case 1:
    return '待发货'
  case 2:
    return '待收货'
  case 3:
    return '已完成'
  default:
    return ''
  }
}

import { makeOrder } from '@/entities'
export default function buildMakeVirtualOrder() {
  return function makeVirtualOrder(raw?: IRawPresaleOrder) {
   const order = makeOrder(raw)
   if(! order || !raw.virtualOrderType) {
     Monitor.warn('脏数据')
     return null
   }
   return {
     ...order,
     virtualOrderType: raw.virtualOrderType,
     virtualOrderDesc: selectVirtualOrderDesc(raw.virtualOrderType)
   }
  }
}

  

• 把前端的逻辑和服务端接口数据隔离开，无论服务端怎么变，前端后续的渲染、业务代码不需要变，我们只需要变更entitiy工厂函数；并且经过entity层处理过后，所有流入后续渲染&交互逻辑的数据都是可靠的；对于部分异常数据，前端应用可以第一时间发现并报警。  
  
• 通过对业务模型进行抽象，实现了模块间的组合、复用。另外，抽象出的entity对代码的维护性也有非常大的帮助，开发者可以非常直观的知道所使用的entity所包含的所有字段。
  

  

• 根据route的query参数以及一些商家类型参数来决定默认选中哪个tab
  

  

• 根据是国内商家还是境外商家，调用对应的供应商接口来更新供应商下拉框
  

{
  mounted() {
    const { subType } = this.$route.query
    /*
      7-15行处理了几种分支链路场景下对subType的赋值问题
    */
    if (Number(subType) === 0 || subType) {
      this.subType = subType.toString()
    } else {
      if (this.user.merchant.typeId === 4) {
      this.subType = this.tabType.cross
      } else {
      this.subType = this.tabType.ordinarySpot
      }
    }
    /*
      getAllLogisticsCarrier有没有对subType赋值呢？光看这段代码完全不确定
    */
    this.getAllLogisticsCarrier()
    /*
      21-22行又多出来一个分支需要对subType进行再次赋值
    */
    if (this.isPersonPermission && !this.crossUser) {
      this.subType = this.tabType.warehouse
    }
  },
  getAllLogisticsCarrier() {
    let getCarrier = API.getAllLogisticsCarrier
    if (this.crossUser) {
      getCarrier = API.getOrderShipAllLogistics
    }
    getCarrier({}).then(res => {
      if (res.code === 200) {
      const options = []
      .......... // 给options赋值
      this.options2 = options
      }
    })
  }，
}

// prepare-order-page.ts
import { tabType } from '@/constants'
interface IParams {
  subType?: number
  merchantType: number
  isCrossUser: boolean
  isPersonPermission: boolean
}
/*
  做依赖倒置主要是为了方便后续的单测和复用
*/
export default function buildPrepareOrderPage({
  queryLogisticsCarriers,
}: {
  queryLogisticsCarriers: () => Promise<{ carriers: ICarrires }>
}) {
  return async function prepareOrderPage(params: IParams) {
  const activeTab = selectActiveTab(params)
  const { carriers } = queryLogisticsCarriers(params.isCrossUser)
  return {
    activeTab,
    carriers,
  }
  }
}
function selectActiveTab({
  subType,
  isCrossUser,
  isPersonPermission,
  merchantType,
}: IParams) {
  if (isPersonPermission && !isCrossUser) {
  return tabType.warehouse
  }
  if (Number(subType) === 0 || subType) {
  return subType.toString()
  }
  if (merchantType === 4) {
  return tabType.cross
  }
  return tabType.ordinarySpot
}

// query-logistics-carriers
export default function buildQueryLogisticsCarriers({
  fetchAllLogisticsCarrier,
  fetchOrderShipAllLogistics,
}: {
  fetchAllLogisticsCarrier: () => Promise<{ data: {carriers: ICarrires }}>
  fetchOrderShipAllLogistics: () => Promise<{ data: {carriers: ICarrires }}>
}) {
  return async function queryLogisticsCarriers(isCrossUser: boolean) {
  if (isCrossUser) {
    return fetchAllLogisticsCarrier()
  }
  return fetchOrderShipAllLogistics()
  }
}
// index.vue
{
  mounted() {
    const {activeTab, carriers} = prepareOrderPage(params)
    this.subType = activeTab;
    this.options = buildCarrierOptions(carriers) // 将carries转换成下拉框option
  }
}

import buildPrepareOrderPage from '@/utils/create-goods';
function init() {
  const queryLogisticsCarriers = jest.fn();
  const prepareOrderPage = buildPrepareOrderPage({ queryLogisticsCarriers });
  return {
  prepareOrderPage,
  queryLogisticsCarriers,
  };
}
describe('订单页准备逻辑', () => {
  it('当用户是国内商家且在入仓白名单上，在打开订单页时，默认打开入仓tab', async () => {
  const { prepareOrderPage } = init();
  const params = {
    merchantType: 2
    isCrossUser: false
    isPersonPermission: true
  }
  const { activeTab } = await prepareOrderPage(params)
  expect(activeTab).toEqual({tabType.warehouse});
  });
   it('当用户是跨境商家，在打开订单页时，默认打开跨境tab', async () => {
  const { prepareOrderPage } = init();
  const params = {
    merchantType: 4
    isCrossUser: true
    isPersonPermission: true
  }
  const { activeTab } = await prepareOrderPage(params)
  expect(activeTab).toEqual({tabType.cross});
  });
  ......
});

type Request = (url: string, params: Record<string, any>) => Promise<any>;
import makeCarrier from '@/entities/makeCarrier'

export default function buildFetchAllLogisticsCarrier({request}: {request: Request}) {
  return async function fetchAllLogisticsCarrier() {
  // TODO: 异常处理
  const response = await request('/fakeapi', info)
  if (!response || !resposne.code === 200) {
    return { 
      success: false
    }
  }
  return {
    success: true,
    data: {
      carriers: response.list?.map(makeCarrier)
    }
  }
  }
}

  

• 监听交互事件并调用对应的usecase来进行响应
  

  

• 通过usecase来获取entity数据进行渲染
  

  

• 迭代频繁的大应用：主要包括代码行数较多、逻辑较为复杂的几个中大型应用。这些应用想要一把梭直接完成迁移成本极高，但同时每个迭代又有相当的需求。基于这种情况，对于这三个应用我们采取了微前端的方式进行迁移。每个应用分别起一个对应的React应用，对于新页面以及部分逻辑已经完全和ui解藕迁移成本不高的业务，都由React应用来承接，最后通过module federation的方式实现融合。  
  
• 迭代不频繁的小应用：剩下的应用均是复杂度不高的小应用，这部分应用迭代的需求不多，以维护为主。因此我们的方案是对现有逻辑进行整洁架构重构，在ui和逻辑分层之后直接对ui层进行替换完成迁移。
  

  

• 单测即文档：上面提到了usecase通过依赖倒置来配合单测落地，后续团队期望将一些业务逻辑的实现细则通过单测的描述来进行沉淀，解决业务文档实时性的问题。  
  
• 完善监控体系：前端常遇到的3种异常包括 代码逻辑异常、性能瓶颈(渲染卡顿、内存不足等)、数据导致异常。对于数据异常，我们可以在entity层映射的过程中加入对异常数据的埋点上报来填补目前监控的空白。（代码逻辑异常通过sentry已经监控，性能监控对于中后台应用不需要）