使用自定义组件进行递归的天坑

[tencent]

使用自定义组件进行递归的天坑

[RubyLouvre]

这不是你一直引以为豪的feature吗，之前一直在群里吹

[yisar]

好吧，我承认我吹，那现在咋办，自定义组件递归去描述一棵树，真的不够优雅

[yisar]

跑了下用例，看到的是，目前是限制死了，5层
这种限制在一颗大的 dom 树的情况下，很令人绝望的

其实我一直搞不懂，为什么支持一下 template 的递归，方便所有人，就是不去支持呢，是因为 template 递归有什么严重问题吗，其他的小程序都是支持的

[JuneAndGreen]

@132yse 关于 template 支持递归我帮你跟相关同事提一下，当前确实是有个递归检测会终止。（其实先前也有考虑过那个方式，wxParser 好像就这么干的来着？只是那个递归检测在就放弃了）

fard 不了解，不过 kbone 是默认利用 5 层静态模板 + 自定义组件拼接的方式来做的，性能直接对比原生纯静态模板会略慢一些，因为会有自定义组件创建开销。但是自定义组件的一个好处是如果做 diff 反而会快，因为不需要整棵树 diff，只需要做 shadow-tree 的 diff。然后其他问题：

1、样式问题因为用了全局样式配置，自定义组件减少封装层，保持自定义组件本身作为一个层级的做法，基本上能确保层级正确，所以 flex 应该大部分情况是生效的。
2、控制台样式这确实是个问题，可以在社区提给工具同学优化一下。
3、这个在适配层就做掉了，应该不影响开发者使用的。

template 支持递归有好有坏，就算 template 支持递归最好也是结合起来封装，因为性能除了初始渲染外，也要考虑局部更新的性能。

[yisar]

@JuneAndGreen 大致观点相同

1. fard 没有写死五层，当前是，view 标签是自定义组件，view 下的简单元素用 template，但是我认为仍然不是的好方式，毕竟到处都是 view 标签的话也不好接受……
2. 关于 diff，fard 就有做，但是 diff 的过程中需要封装过多的逻辑去 hack 掉 template 不支持递归的问题。这部分逻辑如果支持了 template 递归，就可以省掉。
3. 完全同意关于自定义组件和 template 结合的方式，也同意局部 diff，其实这个机制在 fard 里叫做 block tree……是 vue 3 最先提出的，但是 vue3 是检测模板的 v-for v-if，相当于我们现在，v-for 外面加一个自定义组件，最初我认为是个很好的机制的
4. 关于控制台样式，如果能做一个约定，比如提供一个 block 组件，这个组件不被控制台显示（和普通 block 标签一样），甚至如果可以的话，希望这个标签可以不是 shadow-dom

综上，目前来说，由于 template 不支持递归，导致 kbone 限制死了层级，导致 fard 限制死了 view 标签，导致 alita 发现层级变多会自己加一个 template
就因为这一个 feature，导致所有的同类框架都不完美，搞定 template 的递归，我们都就可以进步了呀

[JuneAndGreen]

@132yse 理解，所以关于 template 递归这个我提了需求过去了，因为不是我在负责编译那块所以我也暂时没有解决办法。

不过我说的 diff 是指基础库的 diff，和我们 setData 的 diff 无关，我们的 diff 指影响 setData 的次数和大小。而基础库的 diff 是源于会将 appService 端的 setData 发给 webview 端，webview 端会对 vd 做 diff，这个 vd 的大小就取决于在不在自定义组件里面了，在里面这个 vd 就是自定义组件的 shadow-tree，在纯静态模板的页面里，就是整个页面的 shadow-tree。

另外 template 应该解决不了控制台都是 view 的问题的，除了自定义组件外应该没法自定义标签的。我觉得要推动工具去为了各个框架专门做控制台面板的显示优化是比较难的，除非提供插件方式支持开发者自己重写 wxml 面板。

[yisar]

@JuneAndGreen 嗯啊，谢谢啦，大家一起提一下
目前就，就先通过 hack 的方式来搞着