发牢骚

最近在检查组员的代码,发现他们在使用el-select的写的有点麻烦,然后出现了以下一个插曲,引发了我的一系列小想法;
功能的需求是这样的:
点击table中每行的修改按钮时,将数据回显。
原列表接口(A接口)给出的数据如下:

[{
id:"00012312",
"name":"jack",
"sex":"0"
},
{
id:"213221",
"name":"lily",
"sex":"1"
}]

allTags接口(B接口):

[{
id:"1",
"label":"泰国"
},
{
id:"2",
"label":"新加坡"
},{
id:"3",
"label":"印度尼西亚"
},{
id:"4",
"label":"马来西亚"
},{
id:"5",
"label":"日本"
}]

点击修改按钮的时候需要把这些数据展示到form表单上,并且form表单还需要展示tags,并且需要用select去展示。可是table的列表的A接口并没有返回tags数据
组员时这么实现的:

  1. 请求allTags接口(B),拿到所有的tags数据,这就是select的option的全部数据;
  2. 获取到该行的id,比如lily的id= 213221,然后根据id再请求另外一个接口(C)去获取该用户的tags的数据
    然后该组员写的el-select的代码如下
                    <el-select v-model="tags"
                               class="information-input"
                               multiple
                               placeholder="请选择标签">
                        <el-option
                            v-for="tag in allTags"
                            :key="tag.id"
                            :label="tag.label"
                            :value="tag.id"/>
                    </el-select>

按照这样的接口设计我觉得这么实现是没有问题的
后来我和组员沟通是不是可以换一个方式,一个简单的功能请求2个接口是不是不好。他给我的回答才是最让我郁闷的,“那接口就这样,你让我怎么办?请求多能实现不就好了”。
后来我又找后台了解,和他们沟通接口设计的是不是有问题,A接口是不是应该把tags直接带给前端,这样是不是就节省一个接口(C),而且我也写过java,我知道一个表连接不难,这个业务涉及到的数据量并不大,甚至可以都不算数据量。

和后台的兄弟说要改接口真的是难啊,就算我一个姑娘去卖萌都不行。最后已经发展到要吵架的地步,才同意改接口。

后来的数据变成了:

[{
id:"00012312",
"name":"jack",
"sex":"0",
tags:["1","2","3"]
},
{
id:"213221",
"name":"lily",
"sex":"1",
tags:["1","2","3"]
}]

我看到又郁闷了,这个数据给过来展示还是没有最大化的精简,列表上需要展示,form表单上也需要展示,那还是要去循环allTags拿label去展示。
我又去找他说,tags这么返回是不是有问题,既然给了我id,为什么不能把label一起给我呢。经过一段时间的你来我往,最后改了。

[{
id:"00012312",
"name":"jack",
"sex":"0",
tags:[{id:"1"...}]
},
{
id:"213221",
"name":"lily",
"sex":"1",
tags:[{id:"1"...}]
}]

接口沟通好之后,我就让组员去重新处理elselect的实现。
好长时间多后,他和我说这样的数据展示不出来,说这样的接口有问题,说了一堆,意思就是我不应该去改接口,现在好麻烦,数据展示不出来。。。。。。
实在不想沟通了,我自己写了代码,其实就是加value-key标示出value对应的key。
value-key使用的重点就是option的value一定要是一个对象

<el-select v-model="tags"
                               class="article-input"
                               multiple
                               value-key="id"
                               placeholder="请选择标签">
                        <el-option
                            v-for="tag in allTags"
                            :key="tag.id"
                            :label="tag.label"
                            :value-key="tag"/>
                    </el-select>

事情到此结束:
回家的路上我在想后台的哥们会不会觉得我是事妈,逼逼个没完,非要改接口,增加他的工作量。
可是我认为,真的优秀代码是要能禁得起推敲的,真的优秀的接口是尽最大的努力给最简单直接的数据。
一个优秀的前端考虑的不仅仅是页面实现,还要考虑性能。性能包括很多方面,接口也是一个方面,如果认为接口不合适,我们应该主动去沟通,这样做出来的产品从内而外都是一个好的优秀的产品。至少目前的我是这么认为的。
我很希望我在的团队是一个有激情的团队,大家有想法有见解,一起向着更高的目标走去。
可是我发现我们团队目前的状态,就两个字混乱,各做各的事情,抱着把工作做完就行的心态,不主动沟通不参与沟通拒绝沟通,像一个个机器人。
现在我陷入自我怀疑和对团队失望的氛围里。。。

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • Nodejs我不多做介绍了,你们可以百度看看百度百科,我为啥用它,很简单,因为公司要用,就想为啥我之前用j...
    编城的南墙阅读 596评论 1 1
  • 今天胖帅肉蟹堡拒绝。第一次被保安驱赶,说我是乱七八糟的推销员。被我强硬的顶回去了,今天没有开个好头,但是后续谈判的...
    荊福卡陈威阅读 158评论 0 0
  • 简书——一个不错的APP 我认识简书,是从一个朋友,不。是同学发的QQ上知道的。 他在里面大发牢骚——“但是我累啊...
    結構阅读 407评论 0 0
  • 伤感与失败,现实与自尊,而人为什么是两撇,一只脚踏出社会,另外一只脚便于回归本源。这是我的理解。 我们生活在一个幸...
    爱发牢骚的一字眉小波阅读 222评论 0 0
  • 今天在食堂兼职,有个笑起来很好看的小哥哥来点餐,我埋头打菜单,打完菜单,一同兼职的小姐姐悄悄对我说,“他对...
    七月上旬11阅读 249评论 0 0