From 6cba64b0e091ecd68eb0ff2ac1a9e10011588c94 Mon Sep 17 00:00:00 2001 From: liubasara Date: Thu, 4 Apr 2024 01:02:20 +0800 Subject: [PATCH] =?UTF-8?q?2024=E5=B9=B4=204=E6=9C=88=204=E6=97=A5=20?= =?UTF-8?q?=E6=98=9F=E6=9C=9F=E5=9B=9B=2001=E6=97=B602=E5=88=8620=E7=A7=92?= =?UTF-8?q?=20CST?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...43\345\206\263\346\226\271\346\241\210.md" | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 "\346\212\200\346\234\257/\347\236\216\346\212\230\350\205\276/\345\207\240\345\260\217\347\202\271\350\257\264\346\230\216\344\270\272\344\275\225KeepAlive\347\273\204\344\273\266\344\270\215\346\230\257\346\234\200\347\273\210\350\247\243\345\206\263\346\226\271\346\241\210.md" diff --git "a/\346\212\200\346\234\257/\347\236\216\346\212\230\350\205\276/\345\207\240\345\260\217\347\202\271\350\257\264\346\230\216\344\270\272\344\275\225KeepAlive\347\273\204\344\273\266\344\270\215\346\230\257\346\234\200\347\273\210\350\247\243\345\206\263\346\226\271\346\241\210.md" "b/\346\212\200\346\234\257/\347\236\216\346\212\230\350\205\276/\345\207\240\345\260\217\347\202\271\350\257\264\346\230\216\344\270\272\344\275\225KeepAlive\347\273\204\344\273\266\344\270\215\346\230\257\346\234\200\347\273\210\350\247\243\345\206\263\346\226\271\346\241\210.md" new file mode 100644 index 0000000..f1261b4 --- /dev/null +++ "b/\346\212\200\346\234\257/\347\236\216\346\212\230\350\205\276/\345\207\240\345\260\217\347\202\271\350\257\264\346\230\216\344\270\272\344\275\225KeepAlive\347\273\204\344\273\266\344\270\215\346\230\257\346\234\200\347\273\210\350\247\243\345\206\263\346\226\271\346\241\210.md" @@ -0,0 +1,24 @@ +--- +name: 几小点说明为何KeepAlive组件不是最终解决方案 +title: "几小点说明为何KeepAlive组件不是最终解决方案" +tags: ["技术", "瞎折腾"] +categories: 瞎折腾 +info: "清明时节雨纷纷，组件缓存欲断魂" +time: 2024/4/4 +desc: 几小点说明为何KeepAlive组件不是最终解决方案 +keywords: ['前端', 'typescript', 'javascript'] +--- + +# 几小点说明为何KeepAlive组件不是最终解决方案 + +大多数框架都提供了基于组件维度 KeepAlive 的缓存机制，然而，前端使用``组件来进行性能优化永远只能是暂时的，最简单的道理就是，UI 的渲染成本已经越来越低了，何况还有 VDOM，用 display:none 属性保存 DOM 结构完全是一种增加心智负担且没有必要的行为。大多数场景下，前端想要缓存的永远是组件中的数据。 + +但是如果是一个用合理的 Headless 架构构建出来的应用程序，它的状态原本就是独立在外层，一层层业务层像洋葱一样把 UI 组件包裹住的，只要页面不关闭，外层的业务层所代表的组件根本不会销毁，所以根本不需要 keep-alive 组件。一旦 UI 重新挂载需要重新加载数据，完全可以让业务层下发这个刷新的能力，让 UI 组件在挂载的生命周期触发即可。 + +这个结论同样也能支持反例，假如使用 keepAlive 组件来包裹 A 组件和 B 组件，那么只要业务够复杂，就一定会遇到 A 组件中的一个小组件 Aa 和 B 组件中的一个小组件 Ba 同属于同一个业务的情况。此时如果业务需要 A 组件和 B 组件不被缓存，但是每次渲染的时候 Aa 和 Ba 又不能重新渲染，在不使用 Store 的情况下，KeepAlive 组件只能通过一些很丑陋的 Include 和 Exclude 来穿透监听，完全违背了职责分离原则。 + +而如果使用 Store，那么其实还是抛弃了 KeepAlive 的组件缓存机制，走了上面所说的数据与 UI 对应的机制，因为很明显 UI 在这里是经过了两次不同的渲染的。甚至我们说在如今前端框架普遍提供了类似于 inject 和 provide 的时代，Store 的存在也显得没有必要了。因为不同业务之间的 Store 相互引用，很容易让不同的业务之间形成网状的结构，其结果就是状态刷新时牵一发而动全身，难以摸清规律。所以如今我们会更倾向于使用简单的 Provide 和 Inject 来让数据之间形成嵌套式的关系，如果遇到共同的依赖，那就再抽离一层子层同时依赖双方，进行双边逻辑的处理，让整个数据流始终保持在自外向内的洋葱结构中，以便在数据刷新时，能够最小化的刷新对应的业务层。 + +结论：前端不应该局限于基于组件级别使用 KeepAlive 进行缓存，前端缓存的最终目标一定是基于业务层的状态进行分层缓存。 + +