Jeecg-Boot项目中deepMerge方法更新导致的表单状态问题分析

问题背景

在Jeecg-Boot项目3.7.4版本中，utils模块的deepMerge方法进行了更新，这一改动导致了一些表单状态管理出现了预期之外的行为。具体表现为：当用户先进行编辑操作（设置了表单字段为禁用状态）后，再进行新增操作时，表单字段仍然保持禁用状态，而按照之前的逻辑应该恢复为可编辑状态。

技术原理分析

deepMerge方法的作用

deepMerge是深度合并对象的方法，在表单状态管理中起着关键作用。它负责将表单的初始配置(formSchema)与动态更新的配置(updateSchema)进行深度合并，生成最终的表单配置。

更新前后的差异

在3.7.4版本之前，当componentProps是一个函数时，deepMerge会直接用新返回的对象覆盖旧的componentProps。而在新版本中，改为对函数返回的对象也进行深度合并，这意味着：

1. 旧版本行为：函数返回的对象会完全替换原有配置
2. 新版本行为：函数返回的对象会与原有配置进行深度合并

具体问题场景

在表单管理中，常见的场景是：

1. 编辑操作时，设置字段为禁用状态(disabled: true)
2. 新增操作时，期望字段恢复为可编辑状态(disabled: false)

在旧版本中，由于函数返回的对象会完全覆盖原有配置，所以可以正常工作。但在新版本中，由于采用了深度合并策略，disabled: true的属性会被保留，导致新增操作时字段仍然保持禁用状态。

解决方案

针对这一问题，开发者可以采取以下几种解决方案：

方案一：显式设置所有状态

在更新表单配置时，显式设置所有可能被修改的属性，包括它们的默认值。例如：

updateSchema([
    {
        field: 'fromOrg',
        componentProps: {
            disabled: !isUpdate, // 明确设置禁用状态
            // 其他属性也需要明确设置
        }
    }
]);

方案二：重置表单配置

在进行新增操作前，先重置表单的配置到初始状态：

function initUpdateForm(data) {
    // 先重置表单
    resetSchema();
    // 再应用新的配置
    updateSchema([...]);
}

方案三：自定义合并策略

如果需要保持深度合并的特性，但又不希望某些属性被保留，可以实现自定义的合并策略：

function customDeepMerge(target, source) {
    // 特殊处理componentProps
    if (source.componentProps && typeof source.componentProps === 'function') {
        return {
            ...target,
            ...source,
            componentProps: source.componentProps()
        };
    }
    // 其他情况使用标准深度合并
    return deepMerge(target, source);
}

最佳实践建议

1. 在表单状态管理中，明确每个操作对表单配置的影响
2. 对于可能被多次修改的字段，建议在每次修改时都提供完整的配置
3. 考虑使用状态管理工具(如Vuex/Pinia)来集中管理表单状态
4. 在复杂的表单场景中，可以建立表单配置的版本管理机制

总结

Jeecg-Boot中deepMerge方法的更新带来了更严谨的对象合并策略，但同时也改变了原有的行为模式。开发者需要理解这一变化，并相应调整表单状态管理的实现方式。通过明确的状态设置和合理的架构设计，可以构建出更加健壮的表单管理系统。