代码结构


 1 product_assets_in_form/item.js.coffee 关联产品入口处
 2 product_assets_in_form/list.js.coffee 关联产品在商机,合同表单处数据隐藏field
 3 product_assets/form.js.coffee 选择商品页面
 4 product_assets/edit_form.js.coffee 编辑关联产品页面
 5 product_assets/tr_form.js.coffee 编辑关联产品table表单一行td

分析需求

需求一开始就搞得交互很复杂，没有必要的交互需要砍掉

图片 1.png

比如后面的需求就砍掉了上面的产品价格的打折功能，主要是由于后台原本的数据结构不支持。--------对产品的需求需要思考

一开始在做这个功能思考的时候，我感到非常的焦虑

1 因为是一个三层关联的场景，(产品--关联产品---商机/合同) 数据结构很复杂，取数据的时候，从后台获取的数据时候，选择产品是产品的机构数据，编辑的时候就是关联产品的数据结构 ----数据怎么取
2 编辑的场景很多，所以需要在前端对数据临时保存与修改的场景很 ----数据怎么保存怎么在页面之间传递
3 页面交互很复杂,批量添加，(怎么解决行合并)批量删除(怎么标识这行数据的唯一性)------------- 数据与页面绑定交互的问题
4 独立版与钉钉办需求不同的时候，代码怎么处理

当然一开始作为一个后端是没有完全考虑到这些关键问题的,所有才有后面的优化

一开始解决这些问题的时候，数据的存储与修改用了前端存储数据库local storage ,在后端取出来就保存起来因为是key value的数据存储格式，就会生成很多的key 而且这些key要有唯一性才能准确取到数据，并且存和取都很麻烦，不适合这种大量数据的多次修改的储存,写起来很麻烦，而且关键的是product product_asset因为两个对象造了不同的数据结构，而最后保存的数据结构只有一种，所以场景一多的时候存储起来会很麻烦

对于这种table的行编辑，一开始做的唯一标示是用的product_id ，确实一开始可以做唯一标示，但是后来产品经理又要加上产品属性这种一对多的属性，这个时候产品id就不能做唯一标示了，这也是后来优化的原因

正确的解决姿势

对于后端数据的存储
要点

1 确认你所用到的数据
数据获取的时侯相同的对象或与关联的对象，最好放在一个大而全的数据结构当中，这个结构需要自己构造，要保证取的时候数据结构是一样的，即使你是从不同的接口获取数据，这个比如product与product_asset,对象里面的数据结构不完全一样，但可以在前端构造这样的比较全的数据结构，
不论什么样的场景都可以维护这唯一一份数据，而不会因为数据的不同的结构，在前端通过if判断而维护多分数据结构。
2 从后端接口获取数据
后端接口尽量保持对象的数据结构，把数据的整合放在前端来做，尽量不修改原来的数据结构，这接口别人也会再用
3 数据保存到backbone的model里面
能解决数据传递的问题，传递model ,collection 就相当于传递了这些数据
页面与数据的绑定，在这里我将table的一行td 新建为一个backbone的class
```
app/assets/javascripts/backbone/views/product_assets/tr_form.js.coffee
```
这个class 在页面当中相当于table的一行，在数据来讲相当于一个model，不管页面在这一行中触发什么事件，我都可以只更改当前的这个model而改变数据，而把确认修改哪一个model的事情交给框架
4 数据的删除
当在页面把这一行移除的时候，数据需要标识哪一份数据需要删除，由于我这边场景是即有可能删除批量选择添加的数据，也会删除本来后端就有的数据，所以对于刚添加的数据，可以直接删除这个model,而已存在的数据需要交_destroy: true的标识传到后端真正的删除
5 写一个明显的变量名
场景一多，虽然也是这两个页面，但是数据的流动，与所做的交互是有所不同，这个时候就需要你传递不同的变量来标识这些场景，比如编辑就会直接到第二个编辑页面，而新增才会从第一个选择数据页面获取数据后再渲染第二个编辑页面，所以这两个页面和里面所做的交互就写在了两个view当中，分别为
```
app/assets/javascripts/backbone/views/product_assets/form.js.coffee
 app/assets/javascripts/backbone/views/product_assets/edit_form.js.coffee
```
并且用 direct_edit 与 new 等这些参数来明确调用
6 独立与钉钉的代码统一
因为需求不一致，所以两边都在开发导致代码不一样，例如独立需要产品属性，钉钉需要产品规格，首先数据的结构还是取最大的一个结构，只需要在前端通过判断标识来确定显示，与方法调取

总结

保证维护同样的一份数据
充分利用框架优点

关联产品功能挖坑与解析