最近总结了一个写代码的办法，如题：
从后果中寻找办法
先举一个简略的例子：
因为在目前所在的公司，常常会有这样一个阶段。
先前端写 demo，json 数据都本人去造，包含一些随机性的 pageList, 简略的还好，遇到一些简单的，就有点懵。
以前都是后端规定好 json 格局后，本人只简略的简单渲染，或者重组就行了，写 demo 相当于本人既是前端，也是一个小型的后端。
比方：
这是一个很简略的 list，混合一个 tab。
针对具体的 tab，我造的 list 的 json 如下：
[changePath: [], // 转化门路
changeTimes: { // 转化次数
number: '', // 值
percent: '' // 占比
},
changePersons: { // 转化人数
number: '', // 值
percent: '' // 占比
},
changeValues: { // 转化价值
number: '', // 值
percent: '' // 占比
}
] 再来一个简单的：
减少了一个细分维度，table 变成了一个带有 children 的父子蕴含关系的 json
，依据 ant- d 的父子 table 的 json 格局来造数据，就是这样的。
偷懒下，间接截图了，其实母本都一样，都是最开始那个 json-item 数据来拓展的。
能够看出，children 外部是一个小的循环，循环的变量必定是所抉择的细分维度，
chirdren 外部的 item 跟母体的 item 一一对应，这样在 render 的时候，就可复用了。
看一个简单的：
对应的 json 格局：
因为呈现了两个【次数、价值】，可能还会呈现 3 个、4 个，所以依据 changeTimes 和 changeValues 曾经满足不了我的需要。
一开始这里我没理清，所以造出来的 demo 数据都是雷同的。
认真看，他们的不同在于 modals 模型不同，【次数和价值】被同一个模型所专用，所以立即想到了应该循环 modals, 而且须要用 modals 的 value 来做 index 索引（不然这里的命名无奈动态化）。
再看一个更简单的：
对应的 json 格局：
其实要说他简单，无非就是多了一个 children，但 children 外部的 item 是须要跟母体的 item 保持一致的. 所以其实了解了第一个母体，联合最初一个渲染的后果 json，找准外部的变量是如何生成的，比方须要通过模型来循环失去？还是须要通过细分维度来循环失去，就迎刃而解了。