form 提交你们用 Server Actions 还是 API route?
项目里两种风格混着用,想统一一下。Server Actions 写起来简洁,但有些场景感觉 API route 更合适。 我的分类: 站内表单、提交后刷新当前页 → Server Actions。 给前端 SDK、移动端、第三方调用 → API route。 需要复杂中间件(限流
这里聚合 CodeNodeX AI 社区中与 React 相关的技术文章和讨论,覆盖概念解释、工具对比、工程实践、常见问题和独立开发经验。
如果你正在研究 React,建议先阅读高质量长文,再参与帖子讨论,形成从理解到实践的完整路径。
项目里两种风格混着用,想统一一下。Server Actions 写起来简洁,但有些场景感觉 API route 更合适。 我的分类: 站内表单、提交后刷新当前页 → Server Actions。 给前端 SDK、移动端、第三方调用 → API route。 需要复杂中间件(限流
听说 TanStack Router 类型安全做得好,拿一个内部工具试了一周。结论是:类型体验确实吊打 Next.js,但生态和心智模型有学习成本。 最爽的是路由参数和 search params 全类型推导,再也不用手写 as string 。 不爽的: 文件路由约定还在演进,
App Router 下做全局 toast,传统的 context + provider 模式套在 root layout 会把整棵树变成 client component,RSC 全废。 现在流行的解法: 用 zustand / jotai 这类非 React Context
App Router 的 loading.tsx 本质是给整个路由包 Suspense,用得好首屏体验起飞,用不好就是 "闪一下骨架屏再闪一下内容"。 踩过的坑: loading.tsx 是静态的,没法根据加载进度切换。 嵌套路由每个 segment 都可以加 loading,层
React 19 终于把 ref 当普通 prop 传了,函数组件不用再 forwardRef 包一层。对组件库作者来说是大好事,API 简洁多了。 但迁移有坑: forwardRef 还能用,但官方标记 deprecated 警告。 既有组件库大改 API,可能要发 major
审计一个慢页面,发现一堆 useMemo 。把 "为优化而优化" 的 memo 删了之后,页面反而快了 30%。 原因:很多 memo 缓存的对象在依赖变化时频繁重建,memo 本身的开销 它省下的渲染。特别是缓存的值只被传给原生 DOM 元素时,完全没必要。 经验法则: 缓存值
接手的项目首屏 JS 1.2MB,扒了下发现一堆组件被无脑标了 'use client' ,整片子树都在客户端渲染。 花了两天做了一次清理: 把不依赖交互的展示组件改回 server。 真正交互的组件下沉到叶子节点。 共享 util 区分 server / client 版本。
做一个不需要 SSR 的小工具,分享一下最精简的 Vite + React + Tailwind 起手配置。 vite.config.ts 里加 Tailwind 插件,CSS 里一行 @import "tailwindcss"; 。不用 postcss、不用 tailwind.
Lighthouse 高分和线上 CWV 不是同一证据。本文按页面任务冻结实验,用实验室预算阻断确定性回归,再用分群字段数据验证真实用户并控制发布。
DOM 代码看起来正确、页面返回 200,都不能证明用户能完成任务。本文把 Playwright 的定位、自动等待、网络与控制台观察、截图和 Trace 组成浏览器反馈环,每轮围绕一个可见差异修正实现。
把截图直接交给 Agent 容易得到只匹配一个视口的像素拼图。本文把参考图拆成内容、布局、状态、组件、资产和验收合同,再安排可逐步验证的实现顺序。
截图相同不能证明键盘可用,自动无障碍扫描通过也看不出错位。本文组合确定性视觉回归、语义断言、键盘与缩放人工检查,建立前端发布证据。