 |
1
数据都从接口的来的，而且很大，不可避免的就是用上 useDeepCompareEffect ，在可编辑虚拟表格等场景下，能明显感觉卡顿，React scan 浏览器插件、f12 性能 tab 都用上，知道是因为重渲导致 deep 本身比较了两次耗时，用了挺多时间一层层排查，确保只渲一次，但未来这个平衡又可能随着需求迭代不经意间被打破。
|
 |
crysislinuxJul 9, 2025 via Android
3
当然是随缘啦。react 和 vue 其实还好，在 signal 时代之前的 angular ，一个页面尤其是有 form 的页面，渲染稳定之前跑几十次 change detection 也是稀松平常。
|
 |
DreamfulJul 9, 2025
5
蹲一下，我也想问大家个问题
你们用 vue 把弹窗封装成组件的时候，关闭弹窗的方式是怎么样的？ 我感觉父组件控制 visible 变量传给子组件，并且把这个变量绑定 v-if ，这样每次关闭组件重新打开都会初始化一次，不用考虑子组件初始化问题（ ps：没有弹窗关闭后缓存数据的需求） 之所以问这个是因为公司有一个大屏项目是实习生写的，所有请求都写在父组件，然后子组件更新数据的时候都得调用父组件的方法来请求。 有些弹窗组件也是跟随大屏打开的时候就初始化了，导致有些变量 provide/inject 接收不到 |
 |
6
@Dreamful 试试我写的弹窗插件 https://vue-modal-provider.netlify.app/
|
|
linkopeneyesJul 9, 2025
7
当然是不管，卡的不行再去管，当然前期什么虚拟滚动，Immer 默认都用上的情况下应该不会怎么卡的
|
 |
user1284Jul 9, 2025
8
当然是命令 ai 狠狠优化了
|
 |
9
过早优化是万恶之源
卡了再说 |
 |
NessajCNJul 9, 2025
11
变状态重渲染的只是状态所在的组件，你把组件拆细一点不就完了
|
 |
12
dan 不是说过么 90%的情况下都不需要考虑性能问题 哪怕重复渲染两次 换到国内业务开发的视角 业务新需求在不断迭代的情况下谁会过分关注性能问题 没到卡的不行的程度都不用管 问就是客户电脑配置不行
|
 |
microscopecJul 9, 2025
14
别担心，我们已经一个人接 20 个项目了，每天对接 3 个后端写接口，慢慢的以后不会再有机会多人合作一个项目了
|
 |
shintendoJul 9, 2025
15
@Dreamful
我喜欢的做法：弹窗组件自己管理 visible ，自己发请求，自己管一切，对外暴露一个 open 方法，父组件调 open 打开弹窗。 |
 |
rb6221Jul 9, 2025
16
有最佳实践也不代表你们能执行啊，先把 code review 搞起来再说吧
|
 |
zhhbstudioJul 9, 2025
17
|
 |
xiaoming1992Jul 9, 2025 via Android
18
看看 useTransition 能不能缓解卡顿
|
 |
shui14Jul 9, 2025
19
你应该把不同类型的表单抽出去，而不是想着生成表单。表单特殊，就是 jquery 都无解
早几年怎么吐槽 antd 的，一大半就是因为它的表单过度封装 题外话，回复楼上，人家 pmndrs resium rn 都能优化，为什么不行 |
 |
shuniaJul 9, 2025
20
把过于复杂，性能要求高的 react 组件抽出来，做成高性能的 react 组件或者直接做成原生 html+js 组件。
什么都用 react 或者 vue 只会害了你。 |
 |
kakkiJul 9, 2025
22
给弹窗组件一个 ref, 直接调用 ref 方法.鸡零狗碎的状态太多就很烦,能自我管理尽量自我管理.
|
 |
lantenJul 9, 2025
23
最佳实践是什么，是问出来的吗？这个推荐那个推荐，不如自己推荐
|
 |
Gilfoyle26Jul 9, 2025
24
@liuidetmks #9 经典
|
 |
leokunJul 9, 2025
25
从业务角度来说，表单的性能高低不会有一毛钱的影响
|
 |
cwwx2022Jul 9, 2025
26
我在网上看到了这个 https://shame-of-react.pages.dev/ ，是关于 react 的
|
 |
liulianccJul 9, 2025
28
@Dreamful #5 我一般父元素通过双向绑定 v-mode visible 控制，子元素 prop visible 、emit('change:visible', true/false)，也不会重新渲染、丢失动画
|
 |
jianv3Jul 9, 2025
29
虚拟列表。 几万条数据也无所谓
|
 |
anivieJul 9, 2025
30
@liuidetmks 真的卡的时候想去优化已经不可能了，只有重写，大部分卡的批爆的网页都是这么来的
|
 |
AV1Jul 9, 2025
31
换个角度想，当你的数据有成千上万行时，你应该考虑提供分页、排序、搜索、筛选、摘要功能，方便用户定位到想要的数据。
|
|
32
把 rxjs 和 context 结合起来咋样，需要暴露和传递的数据，别 props 一层层传状态，让组件订阅所需外部状态的变化，而不是从 props 中获取，感觉有空可以琢磨下
|
|
33
@Chuckle #32 还真有现成的 https://react-rxjs.org/docs/getting-started ，确实能想到估计也有人做过了（
|
 |
RedNaxJul 10, 2025
34
想集成 rxjs 可以看看 focal：
https://github.com/grammarly/focal |
 |
realJamespondJul 10, 2025
36
换 zustand 细粒度更新，直接子组件之间互相作用，绕过 state+context 从根组件全刷
|
 |
GiantHardOct 23, 2025
38
@Chuckle #32 如果打算用 Context 传递 Observable 状态，不如用 mobx ，因为 rxjs 的 API 过于庞大（各种 operator, subject ），而 mobx 的 API 则要精简很多（ observable, aciton, autorun/reaction, computed ）。
另外，mobx 还有 babel/swc 的插件 https://github.com/christianalfoni/mobx-react-observer ，可以自动将组件包装成 observer ，代码中会少很多语法噪音。 除此之外，mobx 相比 rxjs 还提供了状态更新 transaction https://mobx.js.org/api.html#transaction ，这在很多时候也是避免由于重复渲染导致性能劣化的有效方法。 不过，选择用 mobx 这样的基于可变数据结构的状态库，就意味着你需要放弃正宗 React 味儿，会大量地打破 rule of hooks 。 |
1
Select Language