vizards

我觉得主要是纯客户端渲染、静态预渲染和服务端渲染三个方式的取舍，怎么根据合适的场景去扬长避短。纯客户端渲染对服务端压力最低，但是数据 API 就要暴露出去、首帧渲染压力大。静态预渲染性能好、资源要求低，但是不灵活。服务端渲染性能好、灵活，但服务端压力大。

比如对于 header footer 这样的组件，它本身不怎么变，更新受开发者控制，预渲染 html 肯定是最好的。对于需要隐藏 API 实现且与用户相关的组件，就不得不选择服务端渲染。对于重客户端型组件，不太要求首帧性能的就选客户端渲染。所以按组件/岛屿区分渲染策略就变成大家共同的选择了。在这个思路上感觉目前还是 astro 想得最清楚，什么 server islands 、live content collections 都加上了，可惜在静态预渲染的灵活性上做的还是不够好，部分依赖 On-demand ISR 的场景得不到第一方支持

首先现在立式消毒柜（非商用）卖不动，商家已经放弃在这个产品上卷了。嵌入式消毒柜功能太鸡肋了，洗碗机就能顺手干掉消毒柜的活。所以购买选择上 洗碗机 > 嵌入式消毒柜 > 立式消毒柜。
然后是关于热风烘干的问题，因为烘干之后水并不会消失，他只是增加了柜内湿度，最终还是要被排到环境中，因为洗碗机本来就要排水，烘干的冷凝水排出方面就有天生的优势，比如西门子的洗碗机就用沸石来吸水蒸汽，在下一个洗碗周期把水排走。普通的洗碗机有两种模式，一种是外循环蒸发，水蒸汽直接排到外部空气中。但外部湿度高怎么维持内部湿度一直低就是个问题，所以有些厂家就开卷巡航模式（ 48 小时内每隔 1 小时烘干 10 分钟这种）。高级点的就用内循环排水，类似除湿机压缩机的原理，把水蒸汽冷凝然后排出，这样的好处是可以完全封闭整个柜体，防止进蟑螂或者虫子，但是成本就高了很多。康宝就有消毒柜在卷这个方向。

https://yueying-docs.effirst.com/yueying-intro.html
看起来像是这玩意插入的 meta 标签。简单看了下，UC 出的

@WangLiCha 实际上如果是单纯的 flex 布局（即使包含 wrap ）直接 flex 排就可以了，拖拽也可以正常工作，只不过由于不定宽高，要自己处理动画变形问题

你的要求 dnd-kit 都可以满足
1. 跨容器拖拽排序官方有 examples ，其实就是定义多个 container ，共享 draggable element ，如果需要的是从源容器复制的效果，则需要源容器内的 draggable element 在被 drop 后重新渲染（通过修改 key 或 id ），这样被拖走后他会在原地重新生成一个，或在拖拽开始/拖到可放置区域时重新生成一个新的 key 以破坏和源容器中的元素的对应关系

2. 限制特定交换顺序：真正的交换是否成功 是看渲染的结果，也就是说 dnd-kit 在拖拽完成的事件里你是否调用 arraymove 等帮助方法让列表数据改变，如果没有改变，那么拖拽就没有成功，列表顺序也不变

3. 每个标签有点击事件：可以通过 sensors 实现只监听某些地方的 pointer 事件，也可以通过监听 onPointerDown 事件来变相监听 onClick ，通过监听延迟来确定是移动还是点击（因为开启了 pointerSensor 后无法监听到 onClick ）

4. flex 不定宽排序：官网有例子，至于拖拽时可能的变形问题，可以通过动态渲染一个 drop item placeholder 实现，即保存一个自定义的 dragoverlay 数据，在元素可以被放置到某个位置但元素还处在被用户鼠标抓住时，插入此 dragoverlay 对应的元素到预测的位置，展现为一个半透明的占位，可以保证布局不变形

我目前遇到的 dnd-kit 较难做到的是多列瀑布流布局下的自由拖拽，拖拽可以实现，但是很难保证容器内不变形

目前（截止 2024.1.10 ） react 还没有真正生产可用的 keep-alive 方案

替代选择：
1. react@experimental 中提供的 unstable_Offscreen ，要求 React 使用 experimental 版本
2. 基于 Suspense 实现的 keep-alive ，比如极简代码实现的 react-freeze ，要求 React 17+
3. 其他介入 React 渲染流程的 hack 实现，比如你已经搜到的

结合路由的方式基本都是手动劫持 Outlet 组件的渲染，使之可以不被 unmount ，转而使用一个新的属性比如 mode 控制子路由组件是否渲染

淘宝敏匠开窗器。非广告，DIY 过一个 90 度旋转开门器正常运行了 2 年。
优点：24V 无刷电机，可以自己 DIY 主控板接，也可以用他们做好的（只能接入米家），同时支持手动和电动操作；
缺点：丑，只能外置，要在门上打钉子。手动推拉需要用力以抵抗无刷电机的阻力。

配合 webpackJsonP 的类似实现，例如重度使用此功能的 webpack5 module federation 可以实现运行时 dynamic import 进相关的 js 代码文件块（加密后），在 service-worker 层挂一个劫持逻辑做解密，或许具有可操作性？编译时要多做一步加密 jsbundle 的操作

目前实践下来最简单的方法是给需要权限的 dom 挂上 data-permission-id （你喜欢的名字），然后在整个 app 顶层用 mutationObserver 集中处理权限并按需隐藏所有的权限 dom ，既实现了框架无关也做到了动态化控制权限无需发布前端代码