对于全新的 React 项目来说，一开始就使用 Next.js、Remix、Shopify Hydrogen、Gatsby 等 React 元框架（Meta Framework）是最正确的选择，这些元框架替你解决了路由、数据加载、服务端渲染（SSR）、全静态页面导出（SSG）、边缘计算、打包器和编译器配置。然而，如果你需要迁移现有的、纯客户端渲染（Client-side Rendering）的项目到 React、或者从其他打包器（如 Vite 或 Parcel）迁移走时，即使在 2024 年，webpack 仍然不失为一种选择。
使用过 React 构建应用的开发者对 React Context 一定不会陌生。在 React 的世界中，相比于把 prop 不断透传给下一层子组件（prop-drilling），React Context 可以更优雅地自上而下将数据从父组件传递到深层级的子组件、并确保数据在不同子组件之间保持一致。不过，Context 绝不是仅属于 React，在 JavaScript 中 Context 一样可以大展拳脚。
去年的这个时候，我把博客从 Hexo 迁移到 Next.js。现在，随着 Next.js 13 App Router 已经稳定，我又把博客从 Next.js Pages Directory 迁移到了 Next.js 13 的 App Router 和 React Server Component。
更新（重新渲染）是 React 的重要特性 —— 当用户与应用交互的时候，React 需要重新渲染、更新 UI，以响应用户的输入。但是，React 为什么会重新渲染呢？如果不知道 React 为什么会重新渲染，我们如何才能避免额外的重新渲染呢？
React 是一个由 Facebook 开源的、可以在任意平台上构建 UI 的 JavaScript 库。在 React 中，一个常见的 Pattern 是使用 useEffect 搭配 useState 发送请求、将状态从 API（React 外部）同步到 React 内部、用于渲染 UI，这篇文章恰恰在向你介绍为什么你不应该直接这么做。
在咕咕了一整年、只发布了三篇文章（其中两篇还是译文）之后，我决定还是稍微花一点时间好好折腾一下自己的博客，以 React 作为抓手，通过 Next.js 和 Hexo 深度共建，对标 Gatsby，打通静态 HTML 与用户交互之间的垂直领域屏障，实现多维矩阵闭环，为个人博客赋能（咳咳咳），然后水出 2022 年第一篇文章（逃） 技术选型：Gatsby vs Next.js 我使用 H...
