Vue组件props数据结构不一致的重构方案咨询

核心原则是把散落在各个父组件的数据转换逻辑统一收口，避免重复实现，不要用Mixin做这类逻辑抽离，推荐按场景选择以下两种可落地的方案：

注意：Appointment.vue作为纯展示业务组件，内部不要掺杂任何不同来源的数据判断、字段兼容逻辑，只认提前约定好的标准入参结构，保证组件本身逻辑纯粹。

方案1：独立适配器函数（最推荐，轻量无侵入） #

用纯函数做数据标准化，所有转换逻辑集中管理，不需要改动现有组件结构，维护成本最低。
首先单独抽离预约模块的数据转换逻辑，统一对齐Appointment组件要求的标准结构：

// 新建 src/adapters/appointment.js 存放所有预约相关的数据格式转换逻辑
/**
 * 将不同接口返回的原始预约数据，转换为Appointment组件需要的标准结构
 * @param {Object} rawData 接口返回的原始数据
 * @param {'create'|'list'} source 数据来源场景
 * @returns {Object} 符合Appointment组件入参规范的标准数据
 */
export function normalizeAppointmentData(rawData, source) {
  // 先定义标准结构的默认值，避免出现空值引用报错
  const standardData = {
    appointment_id: rawData.appointment_id,
    user: {
      user_id: null,
      name: null,
      address: {
        full_address: null
      }
    }
  }

  // 根据不同数据来源做字段映射
  switch(source) {
    case 'create':
      // 适配创建预约页接口的返回结构
      standardData.user.user_id = rawData.user_profile?.user_id
      standardData.user.name = rawData.user_profile?.name
      standardData.user.address.full_address = rawData.user_profile?.address?.full_address
      // 其余业务字段按映射规则补全即可
      break
    case 'list':
      // 适配预约列表页接口的返回结构
      standardData.user.user_id = rawData.user_id
      standardData.user.name = rawData.user_name
      standardData.user.address.full_address = rawData.full_address
      // 其余业务字段按映射规则补全即可
      break
    default:
      throw new Error(`未识别的预约数据来源类型：${source}`)
  }

  return standardData
}

后续所有父组件不需要自己写零散的字段赋值逻辑，直接调用适配器即可：

• CreateAppointment.vue中的调用简化为：

import { normalizeAppointmentData } from '@/adapters/appointment'

export default {
  methods: {
    async openAppointment() {
      const result = await getCreateAppointmentApi() // 原有接口请求
      if (result) {
        this.data = normalizeAppointmentData(result, 'create')
      }
    }
  }
}

• AppointmentList.vue中的调用简化为：

import { normalizeAppointmentData } from '@/adapters/appointment'

export default {
  methods: {
    async openAppointment() {
      const result = await getAppointmentListApi() // 原有接口请求
      if (result) {
        this.data = normalizeAppointmentData(result, 'list')
      }
    }
  }
}

这个方案的优势：

• 纯函数无副作用，方便写单元测试，后续新增第三个调用场景时，只需要在适配器里加一个映射分支，不需要改动现有业务组件
• 逻辑完全集中，后续某个接口字段变动时，只需要修改适配器里的一处映射规则，不用全项目找零散的转换代码
• 没有额外组件嵌套开销，所有逻辑来源清晰，没有隐式依赖

方案2：薄包装组件（适合调用场景极多的情况） #

如果后续Appointment组件的调用方超过3个，不想每个父组件都手动引入适配器函数，可以在业务组件外加一层极薄的包装组件，把转换逻辑封装在包装层。
比如新建StandardAppointment.vue作为统一入口：

<template>
  <appointment v-if="standardConfig" :config="standardConfig" />
</template>
<script>
import Appointment from './Appointment.vue'
import { normalizeAppointmentData } from '@/adapters/appointment'

export default {
  name: 'StandardAppointment',
  components: { Appointment },
  props: {
    rawData: {
      type: Object,
      required: true
    },
    source: {
      type: String,
      required: true,
      validator: (val) => ['create', 'list'].includes(val)
    }
  },
  computed: {
    standardConfig() {
      return normalizeAppointmentData(this.rawData, this.source)
    }
  }
}
</script>

之后父组件调用时，不需要关心转换逻辑，直接传入原始接口数据和来源标识即可：

<standard-appointment :raw-data="apiResult" source="create" />

不推荐使用Mixin的原因 #

Mixin不适合这类场景的核心问题是隐式依赖太强：

• 组件里调用转换方法时，很难第一时间定位方法来自哪个mixin，代码可读性差
• 多个Mixin共存时容易出现同名属性、方法覆盖的问题，排查bug成本极高
• 逻辑链路不透明，后续维护时很容易改漏

内容的提问来源于stack exchange，提问作者Aeria Gloris