💡
原文中文，约3700字，阅读约需9分钟。
📝
内容提要
本文作者在重写个人站点时尝试了NextJS的RSC架构，并记录了一些实践经验。作者尝试了不同的数据传递方式，包括使用Zustand和React Query，但都存在问题。最后，作者决定使用Jotai作为数据管理方案。文章还提到了React Query的数据缓存和潜在的数据泄露问题。
🎯
关键要点
- 作者在重写个人站点时尝试了NextJS的RSC架构，并记录了一些实践经验。
- SSR架构中，服务端请求的数据必须与客户端一致，以避免水合错误。
- RSC架构中，路由由服务端完全接管，需确保浏览器水合时数据一致。
- 作者最初尝试的数据传递方式是通过props传递可序列化的数据。
- 使用Zustand作为状态管理方案未能解决水合错误，作者决定转向Jotai。
- React Query提供了Hydrate组件，但无法精确控制组件的粒度更新。
- 使用React Query时需在Server端建立QueryClient，并在Hydrate时使用Server Side的QueryClient。
- 数据缓存的cacheTime参数影响Query实例的存在时间，需合理设置以避免数据丢失。
- 潜在的数据泄露问题：多个用户访问同一站点时，QueryClient可能缓存不同用户的数据。
- 建议通过meta键值控制哪些query需要hydrate，以避免敏感数据泄露。
- React Query的复杂性促使作者考虑其他数据管理方案，如Jotai。
🏷️
标签
➡️
