共计 969 个字符,预计需要花费 3 分钟才能阅读完成。
最近总结了一个写代码的办法,如题:
从后果中寻找办法
先举一个简略的例子:
因为在目前所在的公司,常常会有这样一个阶段。
先前端写 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,找准外部的变量是如何生成的,比方须要通过模型来循环失去?还是须要通过细分维度来循环失去,就迎刃而解了。