Tailwind 还是 CSS Modules?给点意见
团队新项目在选样式方案。我个人偏 Tailwind(不用起类名,复用方便),但有几个老成员觉得 utility class 像 "在 HTML 里写 CSS",可读性差。 我的看法: 小到中型项目、组件复用多 → Tailwind 真香。 设计系统复杂、需要强语义 class →
这里聚合 CodeNodeX AI 社区中与 React 相关的技术文章和讨论,覆盖概念解释、工具对比、工程实践、常见问题和独立开发经验。
如果你正在研究 React,建议先阅读高质量长文,再参与帖子讨论,形成从理解到实践的完整路径。
团队新项目在选样式方案。我个人偏 Tailwind(不用起类名,复用方便),但有几个老成员觉得 utility class 像 "在 HTML 里写 CSS",可读性差。 我的看法: 小到中型项目、组件复用多 → Tailwind 真香。 设计系统复杂、需要强语义 class →
项目里不少同事为了 "可读性",喜欢在 .css 里用 @apply 把 utility 拼成语义 class。表面上干净了,但我觉得这违背了 Tailwind 的初衷。 问题: 失去了 utility first 的就地可读性。 purge 之外的地方容易出问题。 维护时既要懂
一个 800+ 组件的中后台项目,dev 启动从 webpack 时代的 90s 降到 Vite 的 3s,但页面越来越多后发现冷启动后第一次访问某些大页面还是会卡几秒。 靠 esbuild 的依赖预构建,大部分场景已经很快了。卡顿主要出现在巨型 route chunk 的首次加
Next.js 15 把 Turbopack 标记 stable,dev 性能确实猛。但我的非 Next 项目(纯 Vite + React)用不上 Turbopack,犹豫要不要迁。 实际对比: Turbopack:仅限 Next 生态,dev 飞快,但插件生态不如 Vite。
接手一个内容站,LCP 4.2s,用户反馈巨卡。三个月逐步压到 1.5s,记录下关键手段。 字体改 self host + font display: swap,省了 600ms。 首屏图片用 next/image + priority,LCP 元素提前加载。 第三方脚本(统计、
SSR + 客户端交互组件,首屏经常出现 "服务端渲染的内容 → 客户端接管后闪一下 → 变成正确状态" 的抖动。体验很糟糕。 常见的几个原因:服务端拿不到 window 、依赖时间戳的渲染、登录态在客户端才恢复。 我的处理套路: 能上 RSC 的全上 RSC,根本不 hydra
Suspense 用得好是利器,用不好就是满屏 loading 闪烁。分享一下我的边界划分原则。 每个异步数据区块单独包一个 <Suspense ,fallback 给骨架屏。 路由级用 loading.tsx (本质也是 Suspense)。 不要把整个 page 包一个大 S
为了减小首屏 bundle,把一堆组件都做成了 dynamic(() = import(...)) 。结果首屏是快了,但交互时一堆 chunk 同时请求,FCP 到可交互反而拖长了。 后来反思:dynamic 不是越多越好,得看组件是否真在首屏外、是否够大。小组件 dynamic
App Router 的 intercepting routes + parallel routes 做模态框,理论很美,实际上首屏从外层路由跳进模态路由时经常闪一下,或者刷新直接进纯页面。 试过的解法: parallel route 的 default.tsx 必须写,否则 4
'use client' 加在哪个层级,一直没标准答案。加太靠上,整棵子树都变成客户端组件,RSC 的好处没了;加太靠下,文件爆炸。 我现在的原则: 叶子交互组件(按钮、输入框、下拉)单独标 'use client' 。 容器组件尽量保持 server,把 client 组件当
一个内部中后台,纯 SPA,没用 Next.js。Vite + React Query + Tailwind,整套组合用下来非常顺手。 React Query 的缓存策略省了巨多状态管理代码, staleTime 配合 keepPreviousData 做分页表格体验极好。配合
小项目选数据请求库,SWR 和 React Query(TanStack Query)二选一,纠结很久。 简单对比: SWR:体积小,API 简单,够用。 React Query:功能全(mutations、devtools、乐观更新),生态大。 我的结论:< 5 个接口用 SW