在我们日常开发项目的过程中，我们不可避免的都要进行前后端交接的部分，而有些时候一些不合理的字段值或者字段命名的不规范都会导致前后端对接过程中遇到一些问题，本文主要是对这些问题做记录，并提供一些作为前端人员而言的一些解决思路
- 驼峰命名法和下划线命名法之间的冲突
按我了解的来说，前端变量命名主要采用的是驼峰命名法，而后端有些数据采用的是下划线命名，这就有一个统一变量名的问题，为此我编写了一个工具函数来做转换
// 驼峰和下划线之间的相互转换
/**
* @param { String } type --- line -> 驼峰转下划线, hump -> 下划线转驼峰
*/
function formatHumpLineTransfer (type, data) {
if (typeof data !== 'object' && data === null) return
// 如果不是数组就是个对象
if (Array.isArray(data)) {
data.forEach(item => formatHumpLineTransfer(type, item))
} else {
for (let key in data) {
let newkey
if (type === 'hump') {
newkey = lineToHump(key)
} else if (type === 'line') {
newkey = humpToLine(key)
}
data[newkey] = data[key]
// 如果转换之后还是和之前一样就不删除
if (newkey !== key) delete data[key]
// 如果键值对应的是数组或者对象的话就再进一步处理
if (typeof data[newkey] === 'object' && data[newkey] !== null) {
formatHumpLineTransfer(type, data[newkey])
}
}
}
}
- 后端传递过来的值为null或者没有这个字段
相信对于前端开发人员来说，大家一定都遇到过这种情况，就是页面上渲染一个字段，这个字段是从后端请求的，而有些时候后端根本就没有这个字段或者这个字段的值为null，有时候这种报错并不好发现，因为有时候不仅页面中使用了这个字段，而且在一个用户交互的逻辑中也用到了这些字段，而这种情况我们前端就要做相应的容错处理，后来我就像能不能在拿到后台返回过来的JSON字段的时候制定相应的规则并进行JSON校验，这样就能避免在后续的页面渲染或者交互的逻辑中使用这些错误的字段
JSON Schema规范，这是一个对JSON进行校验的一套准则，可以根据自己的情况编写相应的JSON模式来进行JSON格式的验证，这边再推荐一个根据这套准则衍生出来的框架，Ajv
虽然说作为前端人员来说可以制定相应的规范来解决上述出现的问题，但随之而来的也会给我们带来一些新的难题
1. 大多数情况下后端传递回来的字段并不需要进行校验，如果对所有的请求进行JSON校验的话会大量增加前端工作人员的无用工作量
2. 这种情况大多数发生在研发阶段，也就是开发环境中，原因可能是后端数据库中的脏数据或是其他什么原因引起的，到线上环境其实并不会出现这种问题
基于上述原因，其实大多数情况下并不会使用JSON Schema进行校验
- 对于后端Api的设计
对于大多数情况下，后端只会使用GET, POST两种请求方式，并且有些时候请求的路径并没有并没有明确的目的，导致有些时候前端使用这些API看路径根本不知道在干嘛，这里推荐一个API的设计规范，RESTFul API
