本文记录了笔者开发一个表单验证器的思考过程，分享出来供大家勘误。

提到表单验证器，网上可以搜索到很多现成的“验证方法库”，不乏很多优秀的基于实践的积累之作。但却无法满足我的需求，因为和所有追求完美的人一样，我需要的是一个更好的表单验证器！所以我要思考的问题是如何使一个表单验证器更好。

首先，我想到的是如何更好的利用现有的众多验证方法？

尽管有很多现成的方法可以用，但是在自己产品的特有逻辑中总有需要自己动手写的。要重用现有的代码，复制粘贴固然可以，如果能构建一种机制使相互独立的验证方法关联起来就能使复用本身更有意义。就像人作为独立的个体，只有个体之间建立了某种关系才能成为群体，建立某种关系的途径我们称为社交，而在这里我把构建验证方法相互关联的机制叫做动态依赖，注意依赖不是require。

“依赖”的使用场景是在自定义验证方法的时候，可以在内部声明要依赖的一个或多个函数。如此，当依赖包含多层的时候便实现了一个链表式的校验。就像众多server端应用对request实现的包装器和过滤器一样，我们实现了多层有序的对输入值进行校验。

接下来我突然觉得臃肿的“验证方法库”应该重新梳理，验证方法本身应该分为两类：基础的和高级的，以此达到方便扩展的目的。

所谓基础是指那些没有任何依赖，且不以业务逻辑抽象为标准的校验函数；相对应的高级就是指可能有其它依赖，且可以应用于某种业务逻辑的校验方法。

在处理方法依赖的过程中，我发现有的基础方法除了待检测的表单域值外如果能传递额外的参数，将更加具有可扩展性。比如一个限定字符长度的方法，需要传递具体的限定长度参数，如果是范围方法则需要两个参数，于是我又在声明依赖方法处加入了传参支持。如此，复用更加灵活。

其次，我想到的是如何更灵活的处理错误信息？

通常配置文件可以一定程度上解决配置信息在使用时的一致性问题，但是因为我们实现了校验方法的依赖，从而使得各个配置信息在其依赖节点上有了特定的执行环境。在配置信息之上就可以提供更多的运行时信息，比如被依赖的校验方法名；同时也可以更好的处理返回的错误提示标识，比如动态返回特定的错误表示。理所当然，所有的这些都是可以通过配置来完成，不管是单独的文件还是通过自定义的形式注入。

既然配置文件已经拆分出来，我又在考虑到载入文件的时候还可以通过检测浏览器语言来动态载入支持的多语言版本。这样做的副作用就是部署的时候无法打成一个包，必须把提示语言文件单独提供。

也许，你想到的比我所述的“更好”，欢迎就设计思路和问题解决方法拍砖。

扫码关注w3ctech微信公众号