Sunsetting 创建 React App
🤖 作者简介:水煮白菜王,一位前端劝退师 👻
👀 文章专栏: 前端专栏 ,记录一下平时在博客写作中,总结出的一些开发技巧和知识归纳总结✍。
感谢支持💕💕💕
本文内容参考自 React博客 Sunsetting 创建 React App 进行记录和整理✍
目录
- Sunsetting 创建 React App
- 弃用 Create React App
- 如何迁移到框架
- 如何迁移到构建工具
- 构建工具的限制
- 路由
- 数据获取
- 代码拆分
- more
- 服务器渲染是可选的
- 服务器组件
- 服务器渲染不仅适用于 SEO
- 如果你觉得这篇文章对你有帮助,请点赞 👍、收藏 👏 并关注我!👀
Sunsetting 创建 React App
2025 年 2 月 14 日 React 官方博客发布Sunsetting构建应用 ,弃用了新应用的 Create React App,并鼓励现有应用迁移到框架,或迁移到 Vite、Parcel 或 RSBuild 等构建工具。
还提供了文档,当框架不适合你的项目时,你想构建自己的框架,或者你只是想通过从头开始构建 React 应用程序来了解 React 的工作原理。
React 官方在 2016 年发布 Create React App 时,还没有明确的方法来构建新的 React 应用程序。
要创建一个 React 应用程序,你必须安装一堆工具并自己将它们连接在一起,以支持 JSX、linting 和热重载等基本功能。要正确做到这一点非常棘手,因此社区为常见设置创建了样板。然而,样板文件很难更新,碎片化使 React 难以发布新功能。
Create React App 通过将多个工具组合成一个推荐的配置来解决这些问题。这允许应用程序以一种简单的方式升级到新的工具功能,并允许 React 团队将重要的工具更改(快速刷新支持、React Hooks lint 规则)部署到尽可能广泛的受众。
这种模式变得如此流行,以至于今天有一整类工具以这种方式工作。
弃用 Create React App
尽管 Create React App 使入门变得容易,但存在一些限制,这使得构建高性能的生产应用程序变得困难。原则上,可以通过从根本上将其发展为框架来解决这些问题。
但是,由于 Create React App 目前没有活跃的维护者,并且已经有许多现有的框架可以解决这些问题,因此决定弃用 Create React App。
从今天开始,如果安装新应用程序,将看到弃用警告:
React官方还在 Create React App 网站和 GitHub 存储库中添加了弃用通知。Create React App 将继续在维护模式下工作,已经发布了新版本的 Create React App 以与 React 19 配合使用。
如何迁移到框架
React官方建议使用框架创建新的 React 应用程序。推荐的所有框架都支持客户端渲染 (CSR) 和单页应用程序 (SPA),并且可以在没有服务器的情况下部署到 CDN 或静态托管服务。
对于现有应用程序,这些指南将帮助我们迁移到仅限客户端的 SPA:
- Next.js’ Create React App 迁移指南
- React Router 的框架采用指南
- Expo webpack 到 Expo 路由器迁移指南
如何迁移到构建工具
如果你的应用程序有不寻常的约束,或者你更喜欢通过构建自己的框架来解决这些问题,或者你只是想从头开始学习 React 是如何工作的,你可以使用 Vite、Parcel 或 Rsbuild 在 React 中滚动你自己的自定义设置。
对于现有应用,这些指南将帮助我们迁移到构建工具:
- Vite Create React App 迁移指南
- Parcel Create React App 迁移指南
- Rsbuild Create React App 迁移指南
为了帮助开始使用 Vite、Parcel 或 Rsbuild,React官方添加了从头开始构建 React 应用程序的新文档。
大多数应用程序都会从框架中受益,但也有从头开始构建 React 应用程序的有效案例。一个好的经验法则是,如果应用程序需要路由,我们可能会从框架中受益。
就像Svelte
有Sveltekit,Vue 有 Nuxt,Solid 有 SolidStart
,React 建议使用一个框架,将路由完全集成到开箱即用的数据获取和代>码拆分等功能中。这避免了需要编写自己的复杂配置并基本上自己构建框架的痛苦。
但是,React 始终可以使用Vite、Parcel 或 Rsbuild
等构建工具从头开始构建 React 应用程序。
继续阅读以了解有关构建工具的限制以及React官方推荐框架的原因的更多信息。
构建工具的限制
创建 React 应用程序并构建类似的工具可以轻松开始构建 React 应用程序。运行 后,将获得一个完全配置的 React 应用程序,其中包含开发服务器、linting 和生产版本。npx create-react-app my-app
例如,如果正在构建一个内部管理工具,则可以从登录页面开始:
export default function App() {return (<div><h1>Welcome to the Admin Tool!</h1></div>)
}
这允许你立即开始在 React 中编码,使用 JSX、默认 linting 规则和打包器等功能在开发和生产环境中运行。但是,此设置缺少构建实际生产应用程序所需的工具。
大多数生产应用程序需要解决路由、数据获取和代码拆分等问题。
路由
Create React App 不包含特定的路由解决方案。如果刚刚开始,一个选项是使用 在路由之间切换。但这样做意味着你不能分享指向你的应用程序的链接 - 每个链接都会转到同一个页面 - 并且随着时间的推移,构建你的应用程序会变得困难:useState
import {useState} from 'react';import Home from './Home';
import Dashboard from './Dashboard';export default function App() {// ❌ Routing in state does not create URLsconst [route, setRoute] = useState('home');return (<div>{route === 'home' && <Home />}{route === 'dashboard' && <Dashboard />}</div>)
}
这就是为什么大多数使用 Create React App solve 的应用程序都使用 React Router 或 Tanstack Router 等路由库来添加路由的原因。使用路由库,我们可以向应用程序添加其他路由,从而提供有关应用程序结构的意见,并允许开始共享指向路由的链接。例如,使用 React Router,你可以定义路由:
import {RouterProvider, createBrowserRouter} from 'react-router';import Home from './Home';
import Dashboard from './Dashboard';// ✅ Each route has it's own URL
const router = createBrowserRouter([{path: '/', element: <Home />},{path: '/dashboard', element: <Dashboard />}
]);export default function App() {return (<RouterProvider value={router} />)
}
通过此更改,可以共享指向 的功能板页面 的链接,应用程序将导航到 仪表板页面 。拥有路由库后,可以添加其他功能,如嵌套路由、路由守卫和路由转换,如果没有路由库,这些功能很难实现。/dashboard
这里需要做出权衡:路由库增加了应用程序的复杂性,但它也增加了没有它就难以实现的功能。
数据获取
Create React App 中的另一个常见问题是数据获取。Create React App 不包含特定的数据获取解决方案。如果刚刚开始,一个常见的选项是在 effect 中使用来加载数据。
但这样做意味着数据是在组件渲染之后获取的,这可能会导致网络瀑布流。网络瀑布流是由于在应用程序呈现时获取数据引起的,而不是在代码下载时并行获取数据:
export default function Dashboard() {const [data, setData] = useState(null);// ❌ Fetching data in a component causes network waterfallsuseEffect(() => {fetch('/api/data').then(response => response.json()).then(data => setData(data));}, []);return (<div>{data.map(item => <div key={item.id}>{item.name}</div>)}</div>)
}
在 effect 中获取意味着用户必须等待更长的时间才能看到内容,即使数据可能已经被提前获取。要解决这个问题,你可以使用数据获取库,如 React Query、SWR、Apollo 或 Relay,它们提供预取数据的选项,以便在组件呈现之前启动请求。
这些库在与路由 “loader” 模式集成以指定路由级别的数据依赖关系时效果最佳,这允许路由器优化数据获取:
export async function loader() {const response = await fetch(`/api/data`);const data = await response.json();return data;
}// ✅ Fetching data in parallel while the code is downloading
export default function Dashboard({loaderData}) {return (<div>{loaderData.map(item => <div key={item.id}>{item.name}</div>)}</div>)
}
在初始加载时,路由器可以在呈现路由之前立即获取数据。当用户在应用程序中导航时,路由器能够同时获取数据和路由,从而并行获取。这减少了在屏幕上查看内容所需的时间,并且可以改善用户体验。
但是,这需要在开发的应用程序中正确配置 loader,并在复杂性与性能之间进行权衡。
代码拆分
Create React App 中的另一个常见问题是代码拆分。Create React App 不包含特定的代码切分解决方案。如果我们刚刚开始,可能根本不会考虑代码拆分。
这意味着应用将作为单个捆绑包提供:
- bundle.js 75kb
但为了获得理想的性能,大家应该将代码 “拆分” 到单独的捆绑包中,以便用户只需下载他们需要的内容。这减少了用户等待加载应用程序所需的时间,因为只需下载他们需要的代码即可查看他们所在的页面。
- core.js 25kb
- home.js 25kb
- dashboard.js 25kb
进行代码拆分的一种方法是使用 .但是,这意味着在组件呈现之前不会获取代码,这可能会导致网络瀑布流。更理想的解决方案是使用 router 功能,该功能在下载代码时并行获取代码。例如,React Router 提供了一个选项来指定路由在加载时应该进行代码拆分和优化:React.lazy lazy
import Home from './Home';
import Dashboard from './Dashboard';// ✅ Routes are downloaded before rendering
const router = createBrowserRouter([{path: '/', lazy: () => import('./Home')},{path: '/dashboard', lazy: () => import('Dashboard')}
]);
优化的代码拆分很难做到正确,而且很容易犯错误,从而导致用户下载的代码超过他们需要的代码。当与我们的路由器和数据加载解决方案集成时,它的效果最佳,以最大化缓存、并行获取并支持“交互时导入”模式。
more
这些只是 Create React App 限制的几个例子。
集成路由、数据获取和代码拆分后,现在还需要考虑待处理状态、导航中断、向用户发送的错误消息以及数据的重新验证。用户需要解决的问题有一整套类别,例如:
可及性
- | - | - |
---|---|---|
可及性 | 错误处理 | 渐进式增强 |
资产加载 | 更改数据 | 服务器端渲染 |
认证 | 导航 | 静态站点生成 |
缓存 | 乐观更新 | 流 |
所有这些协同工作,以创建最佳的加载顺序。
在 Create React App 中单独解决这些问题中的每一个可能很困难,因为每个问题都与其他问题相互关联,并且可能需要用户可能不熟悉的问题领域的深厚专业知识。为了解决这些问题,用户最终在 Create React App 之上构建了自己的定制解决方案,这是 Create React App 最初试图解决的问题。
尽管我们可以在 Create React App、Vite 或 Parcel 等构建工具中自己解决所有这些部分,但很难做好。就像 Create React App 本身将多个构建工具集成在一起一样,需要一个工具将所有这些功能集成在一起,以为用户提供最佳体验。
这类集成了构建工具、渲染、路由、数据获取和代码拆分的工具被称为“框架”——或者如果更喜欢称 React 本身为框架,可以称它们为“元框架”。
框架对构建应用程序提出了一些意见,以便提供更好的用户体验,就像构建工具施加了一些意见以使工具更容易。这就是为什么React 开始为新项目推荐 Next.js、React Router 和 Expo 等框架。
框架提供与 Create React App 相同的入门体验,但也为我们在实际生产应用程序中无论如何都需要解决的问题提供解决方案。
深入探究
服务器渲染是可选的
React推荐的框架都提供了创建客户端渲染 (CSR) 应用程序的选项。
在某些情况下,CSR 是页面的正确选择,但很多时候并非如此。即使开发的大部分应用程序都是客户端的,也经常有单独的页面可以从服务器渲染功能中受益,例如静态站点生成 (SSG)或 服务器端渲染 (SSR),例如服务条款页面或文档。
服务器渲染通常向客户端发送较少的 JavaScript,而完整的 HTML 文档通过减少总阻塞时间 (TBD) 来生成更快的首次内容绘制 (FCP),这也可以降低与下一次绘制的交互 (INP)。这就是为什么 Chrome 团队鼓励开发人员考虑静态或服务器端渲染,而不是完整的客户端方法,以实现最佳性能。
使用服务器需要权衡取舍,而且它并不总是每个页面的最佳选择。在服务器上生成页面会产生额外的成本,并且需要时间来生成,这可能会增加首字节时间 (TTFB)。性能最佳的应用程序能够根据每个策略的权衡,按页选择正确的渲染策略。
如果我们愿意,框架提供了在任何页面上使用服务器的选项,但不会强制使用服务器。这允许为应用程序中的每个页面选择正确的渲染策略。
服务器组件
React推荐的框架还包括对 React Server Components 的支持。
服务器组件通过将路由和数据获取移动到服务器,并允许根据我们渲染的数据(而不仅仅是渲染的路由)为客户端组件进行代码拆分,并减少交付的 JavaScript 数量以实现最佳加载顺序,从而帮助解决这些问题。
服务器组件不需要服务器。它们可以在构建时在 CI 服务器上运行,以创建静态站点生成的应用程序 (SSG) 应用程序,也可以在运行时在 Web 服务器上为服务器端渲染 (SSR) 应用程序运行。
有关更多信息,请查看 引入零包大小的React服务器组件的介绍 和 docs。
注意
服务器渲染不仅适用于 SEO
一个常见的误解是服务器渲染仅用于 SEO 。
虽然服务器渲染可以改善SEO ,但它也可以通过减少用户在看到屏幕上的内容之前需要下载和解析的 JavaScript 数量来提高性能。
这就是为什么 Chrome 团队鼓励开发人员考虑静态或服务器端渲染,而不是完整的客户端方法,以实现最佳性能。