做底层先别考虑出不出头，兴许会饿死

看会数据结构的讲课视频，一会就困了

我们现在正在尝试，还没部署到生产环境。感觉功能还挺丰富的，但文档有些过于简略了。

有个叫 ZimaBoard 的 x86 卡片主机

PlanetScale
upstash

@jokimina sony 大法好

大法呀，屏幕好不挖孔，比例适合看电影

@Pencillll 1. 后台本来验证就不能省，页面反正在客户端，用户怎么折腾又没法管，其他的 state 保存方式并不能避免这些问题。
2. 用户认证是另外的问题，用 url 管理 state 并不会将 token 也存在 url 里。共享带 state 的 url 可以让对方直接到达特定的 app 状态，这其实是优势。
3. 主题颜色不涉及到 client 和 server component 之间的状态传递，放在顶层的 theme provider 里即可。同第二点，这种做法可以让前进/后退在历史状态序列里移动而不是只跳转页面，很多情况下是更方便的。如果针对琐碎的输入不想将每个状态都存入历史，可以在跳转的时候使用 replace 而不是 push 。

@BugCry 从 url 拿到的都是值，react 也会对内容转义，基本不可能会被当成逻辑执行。我的理解将 state 放在 url 里至少不会更不安全。
有什么 xss 的实际例子吗？

@BugCry 暴露给客户有什么问题？

@BugCry 1 确实是一个硬性的限制，浏览器限制在 2048 字符以下，一般而言是够的，如果把使用 url 存储 state 作为一个原则的话可能会遇到极端情况无法处理。长 url 还会带来难以记录和共享的问题，优势是能将 app 恢复到特定状态。
第 2 点风险在哪里？客户端 state 本来就存在客户端，不管存在 context ，localstorage 还是 cookie 里，客户都是随便改的，服务端反正都得做验证，需要应对什么？

前几天刚出了新品带摇杆的 studio

尽量把客户端组件推到组件树的末端，需要获取数据的时候一律在上层的服务器组件处理。
如果需要在客户端组件的下层导入服务器组件，将服务器组件作为 children props 传入。同理 ui 库的 context 也可以用这种方法在组件树的顶端导入而不影响下方的服务器组件。
类似于 antd 这种强烈依赖 context 的组件库用起来比较麻烦，建议使用 tailwindcss 以及 shadcn/ui 。

monorepo

server action 补齐了 next.php 的最后一块拼图:P
next 致力于砍掉所有的 API ，同时也就简化了页面的状态管理。有关数据的逻辑都放到 server 端执行，页面上只管展示的部分。
conf 没顾上看直播，今天补一下。看了点 blog ，next14 主要做各种优化吧，使用上没有什么变化，加了个增强安全的 Taint api 。
前一阵开始用 app router 开发，感觉页面上是干净了不少，但是心智负担从状态管理移动到了区分代码在服务端和客户端