说实话真的蛮好笑的，一堆人对着被制裁供应链的伤筋动骨的菊厂员工大谈世界范围内的自由竞争，哈哈哈哈。
颇有古人何不食肉糜那味道了。

这概念其实不新了，没必要喷

据我所知微软应该用了很久了，他们的 SAAS 提供内嵌 react 组件的功能

github 的 repo 像 996.icu 那样的自救呢？动起来啊！怎么这么重的铁拳砸下来直接哑巴了？

按我理解，这个问题无论从哪方面解决都比用纯技术解决成本要低，所以就不用技术去解决了，就这么简单。

同样的接口返回不同的数据结构就得这么做，这样的设计不是很常见吗

说实话很多人喷过早焦虑

但是我现在 31 ，我发现没有在 20 多出头那会进行积累的人，到了 30 多基本没起色，也没有动力和能力去改变自己了

我还是比较庆幸几年前焦虑的工作，焦虑的提升自己过了

啥几把玩意总监？

没想到框架中包含了快 2000 张表，数百万的历史代码。

这你还能没想到？这不该立项的时候就得整清楚？最核心的要做的地方你都不知道大概怎么做，这项目就能定时间开始？

看完了我可以说项目失败这总监基本全锅

另外更不用说有可能是三方甚至多方参与的讨论了，每人复制一遍问题再写自己答案你会疯的

相反，大家按顺序编辑正文，可以把所有回复列在问题下面，一目了然

编辑邮件来进行 Q&A 回答是非常常见的邮件办公模式

考虑你说的情况，实际的邮件 loop 会是：

userB: 请看补充标注
userA: 请看补充问题
userB: 请看标注
userA: 请回答问题?
Q1: XXX
A1: YYY
Q2: ZZZ
A2: CCC
Q3: VVV

如果基于这种模式，大家只要找到这一个块就能迅速得到讨论过程和最终结论，而如果按你的想法，通过正文不断回复
那实际上邮件的 loop 会变成这样：

userB： 补充回答
Q1
A1
Q2
A2
Q3
A3

userA：补充问题？
Q1
A1
Q2
A2
Q3
userB: 回答
Q1
A1
Q2
A2
userA：问题？
Q1
Q2


整个邮件的可读性才会变得极差，容易误读，也难以追溯讨论过程。

type 的虚拟节点下的真实数据，也需要按父子关系把树构建出来，并且当前节点在树上到根节点也连带出来（向上时，如果节点数据不属于此 type ，也需要展示，此时加一个 readonly 标记）

==> 没太明白，如果节点 type 不属于这个 type 也要展示而不是裁剪，那岂不是 type 的树就和原始树一样吗？

B 既然依赖 A 的结果，那你定义 useFetchB 的时候给个入参就行了，这样所有用到 fetchB 的地方就必须传入 A 的结果

如果 A 的查询和每个页面内容无关，那直接把 A 写到 useFetchB 里面去

102

@kxxoling 有拜登因为感冒去隔离的新闻吗？没有搜到

太简单了，学拜登就行了

作为蓝星第一强国的总统，以他作为行为准则肯定没错

拜登会因为感冒去隔离，天天做核酸吗？