@Forviler #33 😀好

@Forviler #27 试了下他的 Demo ，似乎也防御不了。

mark. 我现在项目用的都是 xss 0 0 ，图方便。看来得换了。感谢楼主预警。

@iorilu 其实 openapi 就是干这个的，但奈何生成工具太烂了，最后只能手写一套 binding ，哎

@yixinlove #22 另外，上面说的是传统前端的思路，前瞻现在 Nextjs 的思路，他是将数据 binding 直接实现在了 RSC ，这意味着你甚至都不需要实现 GraphQL API 那套了。前端直接在胶水层把数据汇聚的工作给你做了。

@yixinlove #22 如果你是抱着学习前端的目的来设计后端 API 的话——那完全没必要。思路完全不同，前端世界所有的工具，都是围绕着表达 UI ，以及实现 UI 与状态数据绑定（交互的），和后端的耦合只有 invoke （请求） 罢了。前端世界最多抽一层作为 API 入口，然后再其他获取时候通过这个 layer 来拉数据，或者实现突变（ POST 等请求）。因此，你作为后端，需要学习的是，如何设计良好的 Restful API ，必要的时候提供聚合数据，以及前瞻性的学习 GraphQL API 那套。

用法的 conventional commitlint 。

https://github.com/conventional-changelog/commitlint

看起来这代主要是语法修补？内置 JIT 的进展在这代上有改进嘛？

所以你这标题党有点过分了吧……尤其是引入这堆暴论。


"强类型语言的人，一谈一个语言，第一步就是谈性能" —— 你确定？强类型带来的是维护上的好处，而且 TypeScript 的编译是抹除泛型，还原成 JavaScript ，真要分裂社区，那为啥微软不移植到 .net runtime ，然后编译成 wasm 跑浏览器上呢？—— 也就是现在 blazor 走的路子。


“因为只要涉及到纯后台的算法程序，从来就不是一效率作为第一标准的
节节高升 18:17:38 都是以结果的精准度作为结果的”

说的好像 PHP 能跑的很精准一样，Python 确实精准，内置的整数类型就是 Decimal ，PHP 是？而且开发效率，真的放眼看一下世界好嘛。Spring Boot 、Asp.net Core 这种注解向的开发体验，以及开发便捷度，算是 Web 体系里面开发效率最高的那一批了…… PHP 单文件就是路由确实爽，但是系统复杂度上来后，开发以及维护体验明显是呈
现下降趋势的。


“php-fpm……但最终真实情况是，包括 java 开发的 web ，也是用的 nginx 来当作前端响应用户的并发软件”

他真的连 Proxy 是干嘛都不知道嘛…… 服务架构是真的没接触过还是咋的，Nginx+fpm 就等于一个应用，fpm 本质就是一个解释器，nginx 碰到了 .php 文件，就把文件发给 fpm ，fpm 解释完后把结果给你（ fpm 、nginx 可以不同服务器），这里的 nginx 完全充当的不同层级啊……


“这些是其他强类型语言完全无法理解的，也坚持多线程才是天下的观点” 这个就更离谱了，Java 的 Netty ，虚拟线程、Kotlin 的协程，C#/Rust 的 Async/Await 不都是你说的“协程”。多动动脑子，Go 协程本质上就是绿色线程，底层是 GMP 模型，本质上就是线程池+调度器，协程本来就是运行时基于线程模型上的进一步抽象罢了。操作系统上根本没有协程的哦。


“但离谱的是，这两家公司根本就没有原创过什么自己的语言”
微软基于 .net 平台的 C#，F#，VB 不是？而且你想发明个语言又没啥难的，难的是编译器以及运行时的实现，以及持久稳定的改善，维持语言特性；而且语言本身不能太糟糕； Go 本身语法上就是开倒车，除了 AOT 、绿色线程外，其他语法都是槽点好吧……以及，你用的 Windows 上最好用，以及支持最新标准的 MSVC 不是？.net runtime 不是？你玩的游戏，只要是基于 Unity 的，用的不是 C#，甚至可能直接上了 .net mono runtime?

其他小槽点都懒得吐槽了……睁眼看看世界，别要自己觉得，世界就像你认知的那样了。

@hemingcn #33 https://i.imgur.com/HgxsUD2.png nicept 可以求邀捏

.gitconfig 里

[http "https://github.com"]
proxy = socks5://127.0.0.1:1086

你这个不是和配置 Github 的 Git proxy 一个思路么？

以前 Fira Code ，现在 Cascadia Mono 。

@libasten 国产的安卓本子都能用，就看对于屏幕素质、以及稳定性有多少要求了😁

Kindle 前天刚出 5.16.2.1 之前（包含）的越狱方案，感兴趣的话可以折腾一下 KOReaderhttps://i.imgur.com/L62ZP7V.png
Ref: https://www.mobileread.com/forums/showthread.php?t=356872

@hugepizza 看起来应该是支持 revalidate searchParams 的。revalidateTag 就是和 Redis Cache Key ，TanStack Query 的 queryKeys 一样的东西，fetch 是可选设置，第三方数据库比如说 DB 拉来的，就得手动设置 tag 了。

Ref: https://nextjs.org/docs/app/api-reference/functions/unstable_cache （应对第三方数据源的缓存函数）
Ref: https://nextjs.org/docs/app/building-your-application/caching#apis （不同 API 对缓存的影响）
Ref: https://nextjs.org/docs/app/building-your-application/caching#data-cache (Fetch 相关的缓存工作在数据缓存中）

Server Components 里我记得可以 Read Cookies ，因此，分页，filter 外的参数，还是使用 Cookies 共享更方便。

Ref: https://nextjs.org/docs/app/api-reference/functions/cookies

P.S NextJS 官方是建议 Server Actions Mutation 时才能修改 Cookies ，RSC 由于 Response 流已经发送，无法设置 Cookies ，但是社区有人做了 Cookies 的方案，实现了 Cookies 共享。

楼上发的三张图都是 React 刚移除 experimental 前缀的 Server Actions 以及配套的 useFormStatus 那些吧 https://i.imgur.com/agAJ0Rd.png

我已经尝试使用 RSC + Server Actions 开发了有一段时间了。总结下来，使用 Server Actions 的方案，其实不如 tRPC 舒服 —— 都是类似的写法，但是 Server Actions 没有中间件的概念，这意味着鉴权啥的都需要你在方法里做😂

按 React 的路径，RSC 用于服务端初次渲染，Server Actions 用于突变、表单（失效状态），但还是有一些边界情况，比如说验证后二次加载获取数据这个分支覆盖不到的，这时候要么 dirty 得将 Server Actions 打破边界，当获取函数用，要么还是得写 `route.js` 定义 API 。

P.S 楼上三张图都是直接 FormAction 里传 Server Actions 的用法，实践里太过恶心了……尤其是前后端穿的状态类型不一致——当你需要使用 Action 返回的 State 就会比较恶心了。此外，必须包装一下 useFormState ，才能比较正确的使用传回来的 State （本质上里面得套个 useEffect ）。
——所以，个人建议 useTransition 里调用 Server Action —— 里面调用就和调用自然函数一样，而且不需要再封装个 Button 组件用 useFormStatus 以使用 Pending （这玩意必须 Form 子级才能用）。

试一下 dism 和 sfc 那两个指令看看？前段时间我也无法更新，跑了之后，帮我把我 override 的字体替换掉了，才可以更新成功。