校验逻辑支持返回更多原始信息，拓展 IValidateResult 能力

[MeetzhDing]

现状

当前的校验逻辑，校验函数只能返回 IValidateResult 数据，数据中仅包含了一条 message 信息。对于一个复杂的校验逻辑，其中可能包含了许多其他的原始信息，这些原始信息可以用于其他的业务场景，甚至是复杂的表单展示。

典型的场景有：自定义滚动到指定页面位置（一个DomSelectorID）、自定义组件展示信息、原始的请求 Error。

formily/packages/validator/src/types.ts

Lines 17 to 42 in 8861ef5

	export interface IValidateResult {
	type: 'error' | 'warning' | 'success' | (string & {})
	message: string
	}
	export interface IValidateResults {
	error?: string[]
	warning?: string[]
	success?: string[]
	}
	export const isValidateResult = (obj: any): obj is IValidateResult =>
	!!obj['type'] && !!obj['message']
	export type ValidatorFunctionResponse =
	| null
	| string
	| boolean
	| IValidateResult
	export type ValidatorFunction<Context = any> = (
	value: any,
	rule: IValidatorRules<Context>,
	ctx: Context,
	render: (message: string, scope?: any) => string
	) => ValidatorFunctionResponse | Promise<ValidatorFunctionResponse> | null

目前的类型设计上，message 部分情况为 string，部分情况为 any。any的情况如下。

formily/packages/core/src/types.ts

Lines 121 to 143 in 8861ef5

	export interface IFieldFeedback {
	triggerType?: FieldFeedbackTriggerTypes
	type?: FieldFeedbackTypes
	code?: FieldFeedbackCodeTypes
	messages?: FeedbackMessage
	}
	export type IFormFeedback = IFieldFeedback & {
	path?: string
	address?: string
	}
	export interface ISearchFeedback {
	triggerType?: FieldFeedbackTriggerTypes
	type?: FieldFeedbackTypes
	code?: FieldFeedbackCodeTypes
	address?: FormPathPattern
	path?: FormPathPattern
	messages?: FeedbackMessage
	}
	export type FeedbackMessage = any[]

这里虽然可以通过类型 hack，通过 message 返回一个 object 类型，但是这样会导致目前已有的 UI 适配库都需要改动，而且类型也不严格准确。

提议

在 IValidateResult 中，新增 info 字段，允许返回 IValidateResult 时额外捎带一个信息字段，可以在字段中包含更多信息。

主要改动点

改动 /packages/validator/src/validator.ts 文件，同时处理 message 和 info 信息。info 字段类型为 any。

formily/packages/validator/src/validator.ts

Lines 18 to 39 in 8861ef5

	export const validate = async <Context = any>(
	value: any,
	validator: Validator<Context>,
	options?: IValidatorOptions<Context>
	): Promise<IValidateResults> => {
	const validates = parseValidator(validator, options)
	const results: IValidateResults = {
	error: [],
	success: [],
	warning: [],
	}
	for (let i = 0; i < validates.length; i++) {
	const result = await validates[i](value, options?.context)
	const { type, message } = result
	results[type] = results[type] || []
	if (message) {
	results[type].push(message)
	if (options?.validateFirst) break
	}
	}
	return results
	}

[MeetzhDing]

@janryWang 这个问题可以帮忙看看吗？一些复杂的表单场景，会有一些特殊的错误处理逻辑。

这个改动个人评估是兼容性变更，且开发工作量不大。如果觉得建议可行，愿意采纳，我也可以进行开发与PR.

[janryWang]

先聊聊你们的需求场景？具体是要做什么？为什么需要附带信息？因为我理解校验信息的唯一消费方就是组件

[MeetzhDing]

典型的场景有：

• 自定义滚动到指定页面位置（一个DomSelectorID）：校验不通过的原因可能是复杂的，用户看到错误文案后，可能需要点击跳转到某个具体的区域
• 自定义组件展示信息：校验信息本身可能是多元的，不一定非要是个纯字符串文案，可能是两句文案，errorMsg + errorDetail，甚至包含了 error 的信息，包含了错误的解决方案信息，用更具丰富的UI展示出来
• 校验出错本身是会有侧边栏组件区消费，侧边栏是整个表单的目录。这个时候错误就不止有错误文案，还有错误的位置，错误的业务类型，等等情况。

我后续仔细看了这块的类型代码，个人觉得比较简单的方法，就是 让 Schema 库中的 Message 类型，直接和 Core 中的类型保持一个，是一个 any 类型。
这样组件兼容、复杂场景都能支持，且改动量也最小。

@janryWang

[MeetzhDing]

Schema 和 Core 的类型这块，其实还有一个问题：

现在很多地方是直接包了一层 stringify 的， 就是有个自带的 | ({} & string)
这个东西的功能我是理解的，但是对于要进行源码开发的情况，这个东西让整个类型系统弱化了非常多。

比如 setDisplay setPattern，其实现在就什么参数都是合法的了，但是本身TypeScript应该提供这种校验能力的。
这种逻辑对于一些使用 schema/tsx 源码开发的情况，影响就很大了。
原生的类型可能必须要被重写才能够作为一个较为可靠的类型定义来使用，是否可以考虑：

类型本身是不包含 | ({} & string) 的，对外导出的类型，根据路径分为两套，一个是有的，一个是没有的？
就比如代码为：

export ISchema = {}
export ISchemaStringify = Stringify<ISchema>