背景
在滴滴实习过程中,在一个需求中发现了一个问题
有一块轮播图。这块轮播图展示的就是该司机城市所参与的保司,如果司机还没参与计划,城市就获取不到,这个时候就展示所有参与的保司
不同城市参与的保司一直在更新,这就需要去手动维护,但是这一点是给我们前端去维护的,我们把保司上传到一个平台上,我们接口是去请求的这个平台的数据。
最初的格式
最初的格式是,一个大对象。这个对象的key是id,代表城市id,value是logo链接。
这样,我们每次维护的时候,很麻烦。
1 | { |
这样的对象有这些缺点:
url链接太多,看起来非常杂乱
完全看不出来,在某个城市id中,到底包含的是哪些保险公司,只能通过有几个url来判断有几个保险公司
最初,我们得手动去一个一个修改,而且还得对着xlsx文件看,而且整个对象看起来会非常复杂,因为key是id。value是一堆url链接,每次找对应的城市id会很麻烦,而且找到后也不能很明显的看出来,我们找到的城市的id对不对,只能看一下保司logo数量对不对。
改造后的格式
可以将这个对象改造,改造成如下格式:
有几个保司就加几个companyXXX,然后在每个城市id对应的value,将url换成对应的保司名字
这样的好处是,能清晰的看出,某个城市id,包含的到底是哪些保险公司
1 | { |
将对象这样改造后,整体可读性大大提升,不会像之前那样杂乱无章
问题解析
相信有些同学肯定想到:
1、为什么要用数组格式,用对象不是很方便吗
解答
这里的配置之所以不把各个保司写成对象形式,是因为这个数据是要通过后端返回给我的,后端对数据格式做了限制,必须是数组形式
2、为什么要用一维数组,不可以把多个保司以及对应的logo合并成一个数组吗
解答
也是因为后端做的限制,必须是一维数组
其他
业务那边会给我们一个xlsx文件,里面就是需要修改的每个城市以及对应的保司,我们需要去读取出数据,这里我写了另外一篇文章,感兴趣的同学可以去看看
当然,我们拿到配置后,也可以把他转成对象,转换方法就是:
1 | const keysNumbers = Object.keys(newCityInsuranceLogo3And4) |