性能问题？ #136
Comments
|
这个处理是有一定优化效果的，可以参考下 #125 ，感觉目前比较有效的优化方式还是对表单进行一定的拆分，使用多个 ncform 来实现 |
|
对于使用 |
|
@AnCoSONG 你试下改成 |
|
@daniel-dx 其实之前也在很多的上面加了这个updateOnBlur，效果不能算好吧，只是把输入时的卡顿变成了失焦后的卡顿，体验很奇怪~ |
这个可以尝试一下~ |
|
#55 这个功能也有一点效果，remove 的字段可以直接不渲染 dom 如果 hidden 的字段也可以不渲染 dom 效果会更好 |
现在已经可用了么？我在config文档没有看到～如果没有的化强烈建议加，现在用hidden做动态表单但是结果还得走一层过滤...如果能auto-remove就很舒服，也可以降低每次更新的数据量 |
|
@AnCoSONG 我这个好像加了个 remove 属性，你可以试下看看，没问题的话我整理下提个 pr |
|
@F-loat 赞，这周末抽下时间合下你的代码 |
|
具体实现上可以再讨论 |
|
@AnCoSONG 能把你出现卡顿的schema整理一下贴出来吗？方便用于调试 |
不好意思公司项目可能不方便透露~我写了一个简化的结构，大致这样 const template = {
type: 'object',
properties: {
array1: {
type: 'array',
items: {
type: 'object',
properties: {
array2: {
type: 'array',
items: {
type: 'object',
properties: {
prop1: {
type: 'object',
properties: {
prop3: {
type: 'object'
},
prop4: {
type: 'object',
properties: {
array3: {
type:'array',
items: {
type: 'object',
properties: {
prop5: {
type: 'string'
},
prop6: {
type: 'string'
},
prop7: {
type: 'string'
},
prop7: {
type: 'string'
}
}
}
},
array4: {
type: 'array',
items: {
type: 'object',
properties: {
prop5: {
type: 'string'
},
prop6: {
type: 'string'
},
prop7: {
type: 'string'
},
prop7: {
type: 'string'
}
}
}
},
prop8: {
type: 'object'
},
prop9: {
type: 'object'
},
prop10: {
type: 'object'
},
prop11: {
type: 'object'
},
prop12: {
type: 'object'
},
prop13: {
type: 'object'
},
prop14: {
type: 'object'
},
prop15: {
type: 'object'
},
prop16: {
type: 'object'
},
...
}
}
}
},
prop2: {
type: 'object',
...
}
}
}
}
}
}
}
}
} |
确实是不渲染dom了但是并没有什么提升～ |
|
类似的结构，我们这边最外层数组有 70 个左右元素的时候，初始渲染就要 1 分钟以上，甚至浏览器会直接卡死，后面对表单拆分后勉强可以接受了，初始渲染大概 10 秒多 dom 节点的渲染确实不是太大的问题，valueTemplate 的开销应该是最大的，某一个属性发生改动后全局的计算属性会多次触发，这块当时也没找到太好的办法，只能加了去抖保证输入不至于太卡 |
|
@AnCoSONG @daniel-dx 现在可以把属性直接去掉了，可以看下有没有更好的实现方式 #137 |
这个已经更新在 |
|
@AnCoSONG 刚刚发了一版，三个包都需要更新，使用上把 hidden 换成 remove 即可 |
是指 在填写表单时整体的表现相近，但是在添加数组项时提升比较大，大概耗时能减少1/3～1/4。 但是有个小问题，在添加数组项时你的表单会出现动画卡顿的情况，就是那个 |
|
我的包好像默认加了去抖，卡顿的问题你可以关闭测一下 {
globalConfig: {
updateWait: 0
}
} |
还是会卡顿哈，updateWait是ms单位是吧，我设到5000卡顿缓解了 |
诶 这个是更新延迟么 那还不能这样设置...... |
|
这个也是治标不治本的，还是得深入调整 ncform 的数据更新机制 |
|
封装了一个 enum-select 组件，直接从 vuex 里获取数据，优化效果还挺明显的 "widget": "enum-select",
"widgetConfig": {
"enumType": "stage",
"filterable": true
}组件示例<template>
<div class="ncform-enum-select">
<el-select
v-show="!hidden"
v-model="modelVal"
v-bind="mergeConfig"
:disabled="disabled || readonly"
:placeholder="placeholder || '请选择'"
>
<el-option
v-for="item of options"
:key="item[mergeConfig.itemValueField]"
:label="item[mergeConfig.itemLabelField]"
:value="item[mergeConfig.itemValueField]"
/>
</el-select>
</div>
</template>
<script>
import { EnumsModule } from '@/store/modules/enums'
import ncformCommon from '@ncform/ncform-common'
export default {
mixins: [ncformCommon.mixins.vue.controlMixin],
data() {
return {
defaultConfig: {
itemLabelField: 'value',
itemValueField: 'key'
}
}
},
computed: {
options() {
const { enumType } = this.mergeConfig
if (!enumType) return []
return EnumsModule[enumType]
}
}
}
</script> |
schema比较大，对象数组嵌套比较多的时候更新文本会非常卡顿，每个text修改可能都要2s去暂停等待，数组变长后会更严重，请问是性能问题么？或者可能是我的使用方式有问题？
期待您的回复
The text was updated successfully, but these errors were encountered: