前后端协作，数据格式转换分工，大家是如果划分职责的

[ {"date":"2019-01-01","name":"sally","data":"123"}, {"date":"2019-01-02","name":"jack","data":"123"}, {"date":"2019-01-03","name":"jacky","data":"123"} ] 

{ "2019-01-01":[{"name":"sally","data":"123"}], "2019-01-02":[{"name":"sally","data":"123"}], "2019-01-03":[{"name":"sally","data":"123"}] } 

• 資深大佬 : sagaxu

  请求一多压力就上来了？请量化分析。

• 資深大佬 : BluesQu

  一般出接口之前都会沟通好 大概的结构 ，所以基本上不会出现上面你贴出来的那样子的结构的差异，如果真的需要转换了，就相互之间再沟通了。按照以往的工作经历，遇到此类问题：前端也有处理过，后端也有处理过。不会划分的很细致谁来解决。

• 主 資深大佬 : lqw3030

  @sagaxu 浏览器处理和服务端集中处理会有区别

• 資深大佬 : optional

  这种程度(stateless)的转换，前后端做都毫无压力啊。

• 主 資深大佬 : lqw3030

  @BluesQu 沟通还是重要，这个项目会开少了

• 資深大佬 : ianva

  有条件可以上 graphql, 就算不上 graphql 前端也需要有自己的领域模型，
  只要把接口 map 到前端的领域模型上即可，
  前端应该基于自身的领域模型去开发，而不是面向后端 api 编码。
  前后端应该在业务开始前定好 schema，前端需要确定领域模型。
  写组件首要的是定接口，也就是 props，了解视觉和交互模型后，就应该确定组件的 props
  接口和组件不应该有依赖，组件对接的页面容器上的业务逻辑上对接前端领域模型的
  如果做不到以上，这个项目前端没有维护的可能性，前后端耦合严重

• 資深大佬 : Demeter

  既然主提到划分职责的话 我的建议是后端处理数据

• 資深大佬 : Akkuman

  我倾向于第一种
• 主 資深大佬 : lqw3030

  @ianva 多谢，受教了

• 資深大佬 : ianva

  @lqw3030 如果有相关的 fake server，原则上前后端不需要沟通，除了在定 schema 的时候，前端基于 fake 的数据基于领域模型完成项目，对接也只是很简单的事情

• 資深大佬 : sagaxu

  抛开剂量谈毒性都是耍流氓，有区别是多大区别？大到能成为必须不能放后端的理由？@lqw3030

• 資深大佬 : M003

  我是前端.我会采用第一种.

  后端并不只服务于前端,也会别的服务会调用.

  第一种.输入结构.看起来也清晰明了.各参数含义明确.方便各业务自行处理.

  第二种,也就减轻了前端循环的一层.但别的服务可不会要这种结构..

  ——-
  我猜是做图表展示的数据结构吧?
  “`
  var obj = {};
  arr.forEach(item=>{
  let {date,name,data} = item
  obj[date] = [{name,data}]
  })
  console.log(obj)
  “`
  ——-

  在写的过程中,发现含义都变化了.
  第一种,一天对应一条数据
  第二种,一天对应一个数组? 在我不长的开发时间中,理解只要是数组,就有可能包含多条数据

• 主 資深大佬 : lqw3030

  @sagaxu 今天工作不怎么顺利吗？

• 資深大佬 : liberty1900

  arr.reduce((acc, {date, …others}) => {
  acc[date] = [{…others}]
  }, {})

• 資深大佬 : dongliangnerd

  @ianva 太难了，不是所有团队都有资源和意愿这么做

• 資深大佬 : ianva

  @dongliangnerd 不是资源和意愿的问题，而是有没有能力，这个架构下开发效率会提升很高，而不是消耗资源，特别是基于 ts 开发，项目的质量不是一个级别的

• 資深大佬 : dongliangnerd

  @ianva 你说的这些，除了前端-> 数据层面的映射，其他的组件、ts 还真没啥能力的要求

• 資深大佬 : raynor2011

  第一次沟通接口的时候定好，后面不会再因为格式的问题改，因为后端和 UI 不应该强烈耦合，不可能你展示方案变一次，后端接口就跟着动一次