我自己的话是所有库都更新到最新的，React v18 ，React-Redux v8 ，RTK (Redux toolkit)，TypeScript ，UI 是自己写不用任何库。

库选自己熟悉的就可以了，存在那么多库的意思就是“都可以”。如果在烦恼这一点，那说明是想整最佳实践，既然想整最佳实践，花点时间来选择不才是正确的吗？

另外就是 Redux 原来的写法已经是官方不建议了，具体可以看这篇文章 https://redux.js.org/introduction/why-rtk-is-redux-today

可以试试这个，能用快捷键来打开，需要自己去设置。

https://chrome.google.com/webstore/detail/sctranslator/icfnljfpacimpcbpammmbclmhenimhfc

忘了在哪篇 React 官方的文章看到的了，反正就是说“VDOM 是一个错误的说法，它令别人感觉是 DOM”，不知道有没有记错，这一点也在上面的一些回复也得到体现。

React 更新 DOM 其实也是你这种方法来更新，不然还能怎样用 JS 去更新 DOM 。

举个例子，面对 100 层深度的 DOM ，第 50 层和 99 层要同时被更新，你会怎样做。`document.getElementById("root").innerHTML = '<div>.........</div>'`吗？ React 的话会直接找到需要更新的节点并进行替换。

你 push 的是 item 的引用（地址）

好耶 终于出来了

目前还是 Redux ，配合 reduxjs/toolkit 能减少一些代码量。

Recoil 还是等正式版出来后才再去考虑是否能替换 Redux 。

const renderRowSpan = data => data.reduce((t, c) => ([...t, { rowSpan: c }, ...new Array(c - 1).fill({ rowSpan: 0 })]), []);

我写了个小 Demo 来展示这种差异（变量名请无视...）
```JavaScript
var t = (() => {
let num = 1;
let cb = undefined;
let cbUpdated = false;
return {
a:()=>([num, (n) => { num = n; }]),
b:(c) => {
if (!cbUpdated) {
cbUpdated = true;
cb = c;
}
cb()
}
}
})();
var f = () => {
let [a, setA] = t.a();
let b = 1
t.b(() => setInterval(() => {console.log(a, b);}, 1000))
return {
tt: () => {
let newNum = Math.random()
setA(newNum)
b = newNum
}
};
}
var tmp = f()
```
在控制台粘贴以上代码后可以看到输出了"1 1"，这个时候输入 tmp.tt() 后会变成 "1 Math.random()"。也就是 state 没有变。但是你就算再次执行 f 函数，输出的 state 依然会是 1 ，因为代码中的 cb 并没有被更新。

这时就需要让 cb 更新来让 t.b 获取新 state ，也就是 useEffect 的 dependencyList 。把上面代码的 b 函数改成：
```
b:(c) => {
cb = c
cb()
}
```
后再次执行 f 函数可以看到成功输出新 state 了。这种特性存在于“闭包中的闭包”。这就是 Hooks 的奥秘，整个 React-Hook 可以理解成一个大闭包。（不知道有没有说错...）

所有数相加后判断奇偶（奇数直接输出 0 ） => 创建长度为 10000 的值全为 false 的数组（ 100 * 100 ） => 然后就是把输入的数记录到数组里（输入为 1 和 5 的情况就是在数组的 1 ，5 ，6 上置 true ，就是枚举数字相加的可能性） => 如果存在 Arr[(sum >> 1) - N] == true 的情况就输出 1

可能你是觉得都用到了 Context （要写 Provider ）不够优雅吗？

看看 https://www.npmjs.com/package/react-signal-slot 这个符不符合你的想法，就是个不用写 Provider 的 event bus

现在一个现象就是，很多人在批判 React Redux 的啰嗦和繁琐，但是 React Redux 却一直在统治地位（用户量）。我粗略看了对比了一下各 React 状态库的 GitHub 中的 used by 和 npm 的下载量，发现 React Redux 要比其他加起来还要多。是不是说明了，啰嗦和繁琐对于其他开发者来说并不是一个缺点呢？

当然，这也可能是一个历史遗留问题，因为 Redux 是 React 团队里的人开发的，虽然现在已经转移了，也和 FB 没什么关系了。在原本没有 hook 的环境下，Redux 的写法确实是十分啰嗦，但随着 hook 的出现这种啰嗦也随之消失了。与其他以简洁为主题的状态库似乎也就是现在仍然需要多写一段 const dispatch = useDispatch(); ，但我觉得这并不算什么问题。

再就是 Redux 的一个配置问题，可以说是十分繁琐了，各种 actions 和 reducers ，虽然 @reduxjs/toolkit 的出现把 actions 和 reducers 整合成 slices 了（还有完整的 TypeScript 支持），依然不能使部分简洁爱好者动心（可以理解，真的还是挺繁琐的）。

再就是某方面的心智负担问题吧，我觉得 Redux 做得挺好的，比如 React 18 中引入的 Concurrent mode 和面向非内部的状态管理 useSyncExternalStore 等等的新概念，在面临如此大的更新的情况下如果要我选择状态管理库，那我只会选择 Redux 了，当然这只是我的看法而已。

Google 的网页翻译我觉得已经是目前最好的了，虽然翻译质量肯定是比不上网页版谷歌翻译的。但是这也是能理解的，首先这个产品使用的人我觉得可以用亿来做单位的，而且这还是个免费功能。你遇到中文的翻译改变应该只会在像 #14 说的这种情况下出现，当 lang 为 "auto" 的情况下是正常的。

顺带一提，网页翻译的重点并不在于翻译质量，而是在面对分割元素时（可以理解为一个句子被同时用多个元素装着），是否可以翻译好。像<div>这<a>是</a>一<span>段</span>句子。</div>这种会被分割开来，不用专门的翻译源来处理根本不可能处理好，我对接过 Google 和 Microsoft 的网页翻译， 在分割的处理上，Microsoft 的网页翻译还不够好。

以前的我：TS 这东西谁会用啊，太恶心了，100 行代码里要写 50 行定义，太啰嗦了。
现在的我：真香

@hwlhwlxyz ❤

@adeng
@Ansen
感谢支持！当时就是想着不宣传不造作甚至连名字和 logo 都整了个看上去就一副老土的样子，只关注在功能本身可以去到什么程度，结果也是显而易见的😢。下个大版本应该会把 logo 和名字都换掉吧，大概。

@Robertwhite 有道辞典如果我没记错的话是需要加载远程 js 的，这方法在 MV3 里已经不能用了。所以这扩展一旦过了 Chrome MV2 的 Timeline 可能就无法使用了😂。但是扩展里有自定义翻译源的功能，倒是可以自己整一个，虽然会很麻烦。。。

已经隐藏了再怎么测量都只会是 0 。不能检测并且没缓存和没预设值的情况下，在自己的组件里解决的话只有一种方法，把 parentElement 的 display 改成 block 。


```
const parentElementDisplay = $0.parentElement.style.display;
$0.parentElement.style.display = 'block';
const { width, height } = $0.getBoundingClientRect();
$0.parentElement.style.display = parentElementDisplay;
```
这是单一父元素被隐藏的情况，如果被隐藏的节点很深的话就对整个树都做这种操作。这种操作可以避免检测到 0 ，但缺点也很明显，要遍历整个树和重渲染造成额外的计算量。

随机出现的，当出现的时候“元素”栏会是空的，一般是切换到其他栏后关闭再开启，不行的话刷新网页再重复上述操作，确实难受。

以前用 jQ 真的“一直”都简洁吗，如果要更新一个 DIV 你是直接 query 它还是在初始化后记录用 var 记录呢。然后随着代码增多，交互增多，记录的越来越多，变量也越来越多，不会觉得很乱吗。更何况还是用的像 var 这种，后面维护起来简直头疼，refactor 都难。综合以上这些点你真的觉得 jQ 更好吗。而且随着 ES 的更新，大多数 jQ 的特性都自带了，使用了 Babel 后更是能让你比较无痛地在旧浏览器使用新特性。然后就是 React 一直推的都是 think like React ，你用 jQ 的思路来做 React 还不如直接用 jQ 。