今天，读这篇 React Server Components: the Good, the Bad, and the Ugly 并且做一些笔记。

总体上，作者是对 RSC 持积极态度。

https://www.mayank.co/blog/react-server-components/

The Good / 优点

可以在组建中直接运行服务端代码去数据，是一个进步。而且可以兼容不同框架的 data loader。

有效减少客户端代码体积。直接从服务端获取渲染好的内容带来更好的用户体验。

The almost good / 算是优点

可以运行服务端代码，相当于实现了一个类似 RPC 的机制。服务端代码可以响应用户操作，比如处理表单。

另外一个好处是，我们不再必须写 fetch 了。

The bad / 缺点

当制作表单时，如果需要 disable 按钮，我们需要把它放到一个独立的组件。因为获取表单内容需要客户端 hook useFormStatus()。

同样的，表单中可能也需要显示错误信息，这个也会用到 useFormSratus()，所以这部分逻辑也要被移动到一个客户端组件中。

但是，问题是：

- 相关的代码被分散到多个组件
- 服务端函数的参数变了，现在需要先传当前状态（参考第二张截图）
- useFormState 的官方文档提供的示例，是错误的（作者的吐槽）

还有，

- 到处需要写 use client
- 在嵌套基层的客户端组件里面，调用服务端组件，可能会需要处理 prop 传递
- 很多组件无所谓运行在哪里，但很可能仍旧被打包到客户端，就因为被某个客户端组件 import 了

所以你需要费一点心力，才能正确减少客户端代码体积。

The Ugly / 丑陋的东西

- NextJS 在服务端组件中，并没有使用原生的 fetch
- 你无法使用 request object，也不能设置 headers, cookies, status codes, redirect 等。除非使用 middleware
- 这些问题，在旧版 nextjs 中不存在

The uglier / 更丑陋的东西

如果说 server side component 能减少客户端代码体积，上面的缺点还好说。但实际上，正相反。

Next.js 12：压缩后 70KB
Next.js 14：压缩后 90KB，解压缩之后 300KB

也就是说，只要用 nextjs，这是能做到的最小的体积了。

要记住，不是所有的用户都有很好的硬件和新版浏览器。大量的 JS 实际上更容易影响用户的使用。

如果你因为要写 nextjs 而买了 Macbook Pro M3，你要意识到这么做哪里不对。

RSC 并不直接输出 HTML，而是一个中间态，叫 RSC payload。也就是说，页面的 HTML 一份，RSC payload 代码还有一份，都被发送到客户端。

不是说好减少客户端代码体积吗？怎么还加倍了呢？

Closing thoughts/ 总结

- RSC 是一个积极的方向，因为可以统一两端的语言。
- React 并没有努力解决在客户端开发时候的一些不足，更像是一个被废弃的 FB 项目

 React 存在大量问题还没有被解决（见截图）

重要的是，这些问题不是已有问题，而且 React 带来的新问题！其他框架，比如 Svelte, Solid, Preact, Qwik, Vue, Marko 等，不存在大部分 React 的问题。

从这一点来说，React 更像是技术债（哇，好严重的指控）。因为，要想解决这些问题，就要去掉 React。

我理解开源项目并非必须要解决所有人的问题，但考虑到 React 和 Next.js 都是为大型公司设计并由这些公司开发（这也是他们在市场推广中经常强调的一点），所以我认为对它们的批评是合理的。

目前的状况，React 和 NextJs 已经被绑定得太过分了，二者的界限变得很模糊。一些 API 渐渐和 web 标准不一致了。Nextjs 不像 Remix 那样尊重 web 标准。

全文在这里，方便您之后阅读

 https://typefully.com/beihuo/69ieBix

读 React Server Components: The Good, the Bad, and the Ugly

我不会写 Emacs 插件，但是 ChatGPT 却能帮我写出来。只要正确的提问，ChatGPT 太适合在自己不熟悉的地方帮忙了。

但是，如何向 LLM 提出正确的问题，会是关键。下面是我的部分聊天记录，可以看到我一开始用了错误方式提问，走了弯路。最后我又去用正确的方式，重新提问，发现效果会好得多。

https://twitter.com/beihuo/status/1739427862179147836

这是前后对比图，可以看到修复之前，css 代码高亮是完全错误的。而且当时所有 @ apply rules 都会显示错误。

我当时并不知道这个可以修复，所以问 ChatGPT 能不能干脆关闭 css 代码高亮。

ChatGPT 没有给我一个满意的答案。因为我稍微知道一些 Emacs 的高亮的 package 名字。所以，当时我还是坚持用自己的知识来引导 ChatGPT 来解决这个问题。

后来的事实证明，这是一个错误的策略。

比如这个对话，我当时试图让 ChatGPT 用配置 tree-sitter 的方式解决问题。仅仅是因为，我知道 Emacs 最新版开始用 tree-sitter 来处理代码高亮。后来我又试图让 Emacs 去识别 @ apply rules。

这些都是同样的错误：试图用自己的受限知识去指挥 ChatGPT。

在几轮对话之后，我发现了一段有意思的代码。看起来，是可以让 Emacs 自己写代码去解决代码高亮问题的。

事情到这里，我意识到了，我最好只描述目前的情况，和我想要的效果。然后让 ChatGPT 用自己的知识去解决。因为在 Emacs Elisp 这块，ChatGPT 比我更懂。

如果渲染效果有问题，我就只用代码例子来说明目前的错误在哪里。ChatGPT 足够聪明，可以分析出来问题，并且给出新答案。

当然，如果答案已经很接近了，只是代码实现有点问题。这时候，可以给 ChatGPT 一些提示。

最后，我让给 ChatGPT 帮我把结果写成了一个 Doom Emacs module。最终代码如下：

现在，让我们看一个改进后的例子。我在第一个消息中，就尽可能描述出现的问题，和想要的效果。并要求 ChatGPT 配置我的 Emacs。可以看出，在第一个回复中，ChatGPT 就给出了那个关键代码。之后，就可以通过继续微调，快速解决问题。

可见当时我错误的询问方式，让我走了弯路。

所以，推荐 @Piglei 分享的这一篇文章。如何向 LLM 提出正确的问题，会成为非常重要的技能。

https://twitter.com/Piglei/status/1742399105891270747

Antirez 的文章， @dotey 翻译了中文版。

https://twitter.com/dotey/status/1742413924396319183

一个正确和错误提问 ChatGPT 的对比

我想想找一个管理工具，给自己用，但是选来选去总是感觉不顺手。今天我在对比工具的时候，忽然意识到并不是工具不顺手，而是我不知道该如何管理项目开发，我不知道该如何正确使用这些工具。

于是我去学习了 Github 团队是如何管理产品开发的，并做了一些笔记：

Github 内部，对于产品开发的管理，分为以下几个阶段：

1.  Opportunities Backlog 机会待办
2.  Project Overview - 项目概览
3.  Feature Overview - 功能概览
4.  Other Backlogs - 其他待办（文档，市场，等）

他们的工作流是这样的：

1. 所有的想法、计划和提案，都先放在 Opportunities Backlog 里面。所以这里包含所有的要做和要调研的事情。

2. 当决定开始做一个项目的时候，在 Project Overview 里面新建一个事项。这个 project 是团队了解目前进行中的工作的地方，管理者是重度用户。

3. 因为 Project Overview 包含了太多的东西，牵扯到太多的团队。所以每一个 feature 都会有一个 Feature Overview Project。

4. 一些由辅助团队做的事项，比如市场营销，可以单独放在其他的 project 中。所以这些事项，会同时存在于这些单独的 project 和 feature overview project 里面。

可以看到，每一级的 project 都和上一级有所重复。这方便特定团队的工作的同时，也可以让更大范围的团队知晓每一项的进度。

再仔细检视，对于每一个 project，最开始的问题只有两个：

1. 使用者是谁？
2. 需要回答使用者的什么问题？

其他的问题，都是次要的问题。

Opportunities Backlog 的使用者是所有关心整个产品进展的人。回答的问题是：

- 哪个团队适合负责某个事项？
- 某个想法能实现什么样的目标？
- 某个事项的当前进展如何？

在 Github，这个阶段的 project 名字叫 Planning & Tracking Pitches。

当一个 Pitch 被接受之后，流程进入 Program Overview。这个 project 的使用者是 manager 们。所以使用更关心的是：

- 进度如何？
- 有没有风险？
- 如果我有问题，该找谁问？
- 下一步的计划是什么？

在 Github，这个阶段的 project 名字叫 Planning & Tracking Roadmap。

从 Github 分享的截图中可以看到，他们使用不同的栏（Field）来回答使用者的问题。

比如 Trending 这一栏，让使用者知道进度和是否有延迟交付的风险，而 Target  Changelog 可以让使用者知道这个事项最终会在哪一版发布。

他们也会用不同的视图，比如 Next/Later 就可以看到下一步的计划。

现在规划阶段已经完成了，接下来，就要转到 Feature Overview 阶段。每一个规划的事项，都会有一个*单独*的 project。

这一点，我们可以从截图中看到，每一个事项的描述里面，都放了一个 project 的链接。他们使用 template 功能，来确保这一点。

OK，说到 Feature Overview 啦！这一阶段，使用者主要关心产品的交付：

- 为了完成某个功能，一共需要做哪些工作？
- 我当前被分配了什么工作？
- 这些工作的先后顺序是什么？
- 我可以开始做哪些工作？
- 团队成员之间的工作分配是否合理？

创建这个阶段的 project，可以先把所有的事项都列出来。然后创建新的栏（Field），回答刚才列出来的使用者会关心的问题。

 比如想知道需要做哪些类的工作，可以做一些分组，比如设计、市场、测试等。然后是时间，我们可以在 Github Projects 有一个非常有用的 Iteration 栏，来规划开发周期。

我特别喜欢这个 Planning View，按照 Iteration 来进行分栏。当你决定要做某个事项的时候，就拖动到相应的 Iteration 里面。然后可以点击按钮将其转换成一个 Issue。在这个事项里面，还可以用 Task 来进一步细分工作，每一个 Task 也可以是一个 Issue。规划完毕之后，可以将其放到总 View 中。

然后将 Overview 按照 Area 分组，一个最基本的项目管理，就完成了。

哦，对了，每一个 Tasklist 都可以包含一个 Tasklist，所以我们继续细分工作成具体的 Issue。

Github Projects 在移动端可用，这是对我来说很有用的。Linear 只支持桌面端。

最后，总结如何做项目管理：

1. 确定哪些群体是使用者
2. 确定使用者关心的问题
3. 在不确定的情况下，先尝试，再逐步改进

看完 Github 团队的整个视频，对我这种产品管理小白，帮助非常大。作为小团队或者一人团队，我认为可以从只设置一个阶段开始，没有必要分成多个 Github Projects。

上述策略，也可以应用到其他管理工具中，比如 Trello。但是我决定先尝试 Github Projects。等我用一段时间，会分享使用体验。

来自 Github 的视频，From disarray to delight: planning with GitHub Projects - Universe 2022

https://www.youtube.com/watch?v=vHUEOYbH8Mo

您可以点击这里到 Typefully 上查看全文：

https://typefully.com/beihuo/0cgKU57