Validation Methods — Timeline & Decision Table

好，咱们现在来看一下验证方法的时间轴，以及这张决策表到底在说什么。这张表其实就是在完整地告诉你，每个验证方法什么时候会被调用，以及在不同情况下，它们会做什么。 第一次页面加载的时候，如果有任何错误，不管是来自系统内部的校验，还是你通过代码设置的外部错误，都会立刻调用 reportValidity 这个方法，把错误信息直接展示出来。也就是说，一上来就让你看到哪里有错。 但之后的每一次触发，比如用户修改输入、或者组件重新渲染时，行为就变得复杂一点了，它会根据三样东西来决定怎么做：上一次有没有外部错误、当前有没有新的外部错误、以及当前内部的 validate 方法有没有检查出错误。 这里有两个最主要的场景你需要记住。 第一个场景，当存在外部错误的时候，我们会先调用 setCustomValidity，把外部错误的消息传给它存起来，然后紧接着调用 reportValidity 去把这个消息渲染出来。也就是说，只要外面告诉你“这个字段有问题”，就立刻显示这条消息。 第二个场景，当仅有内部错误的时候，也就是说用户自己的输入不满足规则，但没有外部指定的自定义错误，我们会先给 setCustomValidity 传一个空字符串，这个动作会把之前可能缓存的外部错误清掉。然后调用 reportValidity，这时候它会重新计算内部 validate 方法的结果，把内部发现的错误直接呈现出来。 那这个模式背后有一个很清晰的实现思路，就是要把“存储错误消息”和“渲染错误消息”这两件事分开。setCustomValidity 的职责是，如果它被调用并且组件正在显示的话，它应该马上更新显示，但同时永远都要把消息缓存起来。而 reportValidity 的职责是，把缓存的外部消息应用上，并且重新触发内部验证，再决定最终显示什么。 这样分开处理之后，就能很好地跟 Flow 运行时配合工作了。因为 Flow 引擎有时候会先存消息，有时候会立刻要渲染，这种存储和渲染的解耦可以确保在各种复杂流程下，错误提示都不会乱掉，总能在正确的时机显示正确的内容。