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

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

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

有个叫 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 里，客户都是随便改的，服务端反正都得做验证，需要应对什么？