@HunSiKing 如果是台式机的话，换个主板吧。旧的出掉还能回血

高级人工智障

可以分享一下楼主订阅的 ssr list 吗？想开拓一下视野

一般 pc 软件不太兼容异形屏，也没听说过哪个软件要兼容带鱼屏，曲面屏。放过 pc 吧，各种恶心的手机异形屏还不够恶心人吗？

安利一下自己写的库，https://github.com/yukinotech/JSBD ，实现 tc39 bigdecimal 提案 https://github.com/tc39/proposal-decimal

1. interface 里面可以用 this
2. interface 可以 extends 另一个类型，比如 interface Props extends ViewProps {name:string}
3. interface 可以多次声明，重载

p.s 本人是能用 type 尽量用 type, 可能是需要和 class 打交道的场景基本为 0

我 tm 的一晚上没睡着，现在还是醒的

@liuidetmks 其实并不是广告，而是降低客诉和研发成本，可以理解为公司的一些小手段。如果 pc 端的用户功能使用有问题的话，客服一般都会引导下载最新版 chrome ，如果还是有问题，才会拉研发 oncall 。因为一般测试都是在 chrome 上测过功能。当然这个是 toB 场景，是客户求你，toC 的话还是你求客户，一般还是要兼容的。

@ChefIsAwesome 这也是困惑的点，因为网上现在一谈 react 就喜欢讲 immutable ，但是我自己实践就觉得 react 本身是不依赖 immutable 那些东西的，所以发个贴，问一下是不是我想错了。。

@iseki 嗯，有道理，所以还是和实际场景相关。这种场景 useEffect 依赖项可能就不会写 theObject ，而是 theObject.xxx ，或者上层组件 setState 的时候，自己{...一遍}，再传给子组件。

但是确实和 1 ，2 楼说的，Pure Component 才会引起渲染的问题，附言 1 里补充了一下

@jjwjiang 纠结主要有 2 点。1. state.xx = xx 这个操作本身，会不会导致 bug 2.因为一直有人把 react 和 immutable 绑定到一起，所以我想弄清楚对 react 的 render 来说 immutable 是必须的吗，还是只需要保证 newState!==oldState 即可

@gogogo1203 你说的道理是对的。Shallow comparison 就是用 === 比较，对象就比较引用，所以浅复制一个 obj ，虽然不能改变 obj 属性里面的引用，但是浅复制后的新 obj 引用就不是原来的了，丢入 setState 能触发新的 render 。这个过程和对象的属性是同一个 referrence 没什么关系吧。而且 onClick1 的注释也说得比较清楚了，不然为啥说 newState[0].name = "ddddddd"就是修改 personList[0].name

为啥要用 hook 发请求呢？像 useSWR 看起来很优雅，一方面 post 请求不适合 useSWR ，另一方面因为是自定义 hook ，请求的返回值必须在组件内使用。而且 useSWR 自身也是知道声明式的局限性，还是提供了命令式的执行方式。绕了一圈又回去了。。

比如说有一个用户点击后可以刷新数据的场景，useSWR 请求的参数（查询的参数和分页的信息）没变，但是对应的数据可能在后端已经更新了。useSWR 就显得很僵硬，只能依赖另一个手动指定的变量来触发更新。

就像楼上说的，直接搞一个状态管理，在 action 里面发请求，修改 store ，然后组件通过状态管理提供的 hook 就拿到 store ，比如 redux 的 useSelector 之类的。

最后夹带一点私货。 推荐一个状态管理库 https://github.com/bytedance/react-model 真的好用

@wonderblank 对的，起码自己可以控制什么时候该 redner

@CookCoder 挺好的，每年更新一次，明年的留个 pr 机会给我（手动滑稽）

自己本地也试过一些 benchmark ，确实绷不住，原生的太快了。

交流群二维码失效进不去了，能再拉一下不，有些问题想讨论讨论

看了一下回答，误解题主的意思的人很多。总结一下认为 1 楼的说法是比较正确的，举个例子：

2 个字节的 utf-8 中
110X XXXX 10XX XXXX 理论可以承载字符 2^11 ，2048 个字符
但根据标准，实际分配给这个段的 unicode 码点范围是 0x81 - 0x7ff ，也就是说只有 1920 个字符，
二进制表示 unicode 码点：0000 1000 0001 - 0111 1111 1111 ，把后 11 位分配到 110X XXXX 10XX XXXX 上，直接位运算是最方便的。
unicode （ 0000 1000 0001 ）=> utf-8( 110|<0 0010>| 10|<00 0001|>) 肯定比
unicode （ 0000 1000 0001 ）=> utf-8 不浪费版( 1100 0000 1000 0000) 运算方便

utf-8 空间完全够用，不像 utf-16 ，空间极限就是 0x10ffff ，综合来看应该是这个原因吧

感觉这种风险无法衡量，因为不清楚这个开户，会把你的资料同步到谁那，会和什么挂钩。比如开通花呗，就有可能和征信挂钩，这还是抛开隐私问题不谈的情况下

i+=1 多写一个字符不会死的。。