背景
近期开始工作遇到些陈旧代码（Vue 2 + Nuxt 2）需要加入客户端验证功能，目前的专案中有各式各样前人尚未统一的验证方式，例如：
- 有些是使用 HTML 原生客户端验证
- 有些是使用第三方套件
- 有些是使用自造的验证方法
- 有些是使用后端验证
如何统一规范验证方式是一大问题，同时也要思考：「要如何避免创造更多的陈旧代码？」
导入客户端验证过程
分析各式各样的可能性，确实有很多种选择，比如：Vuelidate、VeeValidate、样式库自带包装验证、自造整套轮子的可能性……
最后经过讨论目光锁定在：「原生的客户端验证」，基于浏览器原生就有客户端验证机制，CSS 也有支持相关的选择器与 JS 约束验证 API看似也十分强大，有什么理由不尝试使用原生的客户端验证呢？
由于这是一门无聊的技术，浏览器标准多是优雅降级并且是各大浏览器共同遵循的方法，正好适合在我们未来可能转型(Vue 2 > Vue 3)期间采用，避免大更新后套件兼容问题又遗留更多技术债 😪，是选择该方向的重点考量。
- 能解决问题
- 能向后兼容
- 相较于导入其他套件更少学习成本
于是很快的在隔天我便提出了第一个可行性方案，让整个团队有实际的案例可以参考讨论。
都同意走向后，接下来就是要将这个方案导入到既有的代码中，同样也在 CodeSandbox 制作了一个理想模型，这里使用 Vue 组件进行包装，抽离常用的字段像是：「发票号码」、「中文姓名」、「会员 ID」：
未来要使用该字段时只需要无脑的套用即可，也方便统一管理锁死了不必要的自由度。由于这些组件都继承自全局 Input ，对全站的字段进行改动也十分方便。
同时也尽可能避免多余的抽象，这些客制化组件可以被当成原生 input 来使用，毕竟我们的陈旧代码验证方式可说是五花八门，必须能够向后兼容导入才行！
总结
前端的技术迭代极快，学会应用最基础的浏览器标准，避免过度依赖套件是我一直十分重视的事情，这次在工作专案中实践这样的想法并实践是一个很棒的经验，有空我再多写些工作相关的分享文章吧。