作者 | 卢克·图梅
译者| 核子可乐
规划| 丁小云
新的 React 文档终于发布了，并且已经在新的 React.dev 域上与开发人员见面。
一直以来，官方文档仍然是初学者学习React的一个很好的起点。 然而，新文档中显示的一些趋势在社区中引起了不小的轰动。
首先，新文档建议在首次启动项目时使用由 React 驱动的框架，如 Next.js 或 Remix，而没有框架的项目开发旧方法则像麻风病人一样被“放逐”到了下拉部分。页面底部。
不确定这样的变化将如何影响网络开发的未来。 作为热门的学习资源，官方文档有特别强的指导意义。 我相信开发社区，尤其是这些缺乏经验的开发者，一定会严格遵循指示，最终在新项目中使用该框架的频率将会大幅降低。 。
新文件什么时候发布？
新的 React 文档于 2023 年 3 月 16 日发布。
事实上，文档的内容早在2021年10月就已经以测试版的形式出现了。当时主要集中在使用Hooks和一些功能组件。 经过近两年的调整，即将推出的版本终于推出，但社区反响不一。
此外，原始文档已降级为旧版本，但仍可供参考。
新文档遵循原始 React 文档
有什么不同？
和整个后端开发领域一样，React 的开发思路也不能停滞不前，而是随着时间的推移而逐渐演变的。
钩子和 useState
有两种不同的方式来组成 React 组件，类组件或函数组件。
过去，如果您需要在组件中存储状态，唯一的选择是使用“stateful”类选项。 更短、更简单的功能组件无法满足这些需求。
随着 React 16.8 中 Hooks 和 useState 的出现，这一切都改变了。 它们改变了游戏规则，现在允许将状态存储在功能组件中。 于是乎，函数组件的风头盖过了更长更复杂的类组件，成为了很多Web开发者的首选。 功能组件兴起后，旧类组件被降级为遗留选项，这也促成了“现代 React”的流行，并使其成为组件编写的标准形式。
原始文档仍然主要关注类组件，因为许多应用程序需要存储状态信息。 提供的大多数代码示例都是基于类选项，代表了当时最流行的解决方案。
虽然旧文档很好地解释了 React 的用法并为新用户提供了示例，但大量旧示例的存在与现实世界中组件的编写方式相冲突。 更令人失望的是，刚开始使用 React 的人甚至不应该立即阅读官方文档，因为它是一种过时的 React 编写形式。
当看到较新的测试文档时，开发者们心生怀疑，“这是测试版本，里面的内容可靠吗？” 面对如此尴尬的问题，新文件显然是想拨乱反正、树立新范式。
创建 React App 已死
Create React App 长期以来一直是创建新 React 项目时的首选工具。 它提供了一种快速创建应用程序所需的一切的便捷方法 - 开发服务器、linting、热重载开发环境、生产的转译和捆绑等等。
最近，Create React App的吸引力开始被Vite抢走，Vite因其明显的速度优势而越来越受欢迎。
新文档也不再使用 Create React App，甚至不再提及它。 但这个版本也没有将Vite作为首选解决方案，并开始公开宣扬使用该框架构建新应用的优势。
Dan Abramov 仅建议 Create React App 作为文档中推荐框架的入门工具。 所以看起来 Create React App 并没有退出游戏，只是不再被关注、推广和维护。
useEffect的必要性被指责
另外，社区提出的另一个指责是，新版本文档在React组件中使用useEffect其实有点过分了。
显然，useEffect 广泛用于许多不必要的情况，它的存在似乎只会使代码更难理解、执行速度更慢。
该文档在相关部分提供了使用 useEffect 的常见案例和综合示例，但这些示例可以以其他更有效的形式编写。
框架已成为至高无上的真理
框架提供了大多数应用程序和网站实际需要的功能，包括路由、数据获取和 HTML 生成。
该文档强调，虽然我们的 React 项目可能不一定需要框架在开始时提供的所有内容，但很可能在未来的某个时候需要它。 如果您使用框架，则可以在必要时轻松添加此新功能。
相反，如果你选择Vite创建项目，那么你就得负责添加额外的库来解决各种功能需求。 根据文档，这提高了应用程序的速度，并使组件协调匹配变得困难。
文档中推荐的框架有 Next.js、Remix、Gatsby 和 Expo。 就我个人而言，我实际上承认使用框架是有好处的，甚至我自己的网站也是使用 Next.js 创建的。 我最初也使用 Create React App 开发网站，但在考虑页面 SEO 并为 Microsoft 信息抓取提供元描述和标题等内容后，该框架证明了其价值。
React.dev 网站本身现在也是用 Next 和 Tailwind 编写的，因此官方团队显然也在走这条路。
但是否有必要将框架视为唯一的优先事项？
这些文档重点介绍了创建具有特殊清晰度的新 React 项目的最佳方法。 只需阅读“我可以在没有框架的情况下使用 React 吗？” 部分感觉项目团队强烈推荐你使用框架。
您实际上可以在不匹配框架的情况下使用 React。 但如果您想使用 React 构建新的应用程序或网站javascript 帮助文档，我们建议使用框架。 但如果你想自己创建各种设置，我们无权阻止。 前进！
SSR（服务器端渲染）
既然如此强烈推荐使用框架，这可能意味着SSR（服务器端渲染）也是新应用程序开发的首选。 从我收集的反馈来看，大多数开发人员确实支持这些趋势。
但我将演奏不同的曲调并分享一些不同的观点。
对初学者不友好
对于刚接触 React 世界的初学者来说，立即接触服务器端渲染很容易令人生畏。
Create React App 的突出之处在于它相对简单且易于使用，任何人都可以用它快速构建 React 应用程序。 除了降低初始学习的复杂度之外，框架和服务端渲染的强制使用也可能成为你接触React的障碍，让初学者无法坚持下去。
说实话，有时候连我自己都无法理解，更何况是这些刚入行的新人。 在我看来，这件事情确实是非常令人沮丧的。
不必要的复杂性
很多网友评论道，“我只想要一个简单的客户端应用程序，不需要服务器端这些无穷无尽的复杂元素。” 事实上，这是有道理的，因为在很多情况下，框架提供的这些额外的内容和服务器元素是完全没有必要的。
有时一个简单的客户端应用程序就足够了，无需将所有内容交给服务器进行渲染！
客户端单页应用程序
试问，客户端单页应用程序是不是被扔进了垃圾桶呢？ React 团队断然否认了这一点。
Dan Abramov 反驳说，虽然他们确实在推动框架作为创建新 React 应用程序的默认框架，但服务器端渲染并不是唯一的选择。
几乎所有这些框架都允许您构建纯客户端应用程序，并且几乎所有框架都可以独立于 Node.js 服务器。
然而，由于文档中描述的各种原因，他们仍然更喜欢推荐框架，但不一定匹配服务器端渲染。 即使使用这个框架，仍然可以创建纯客户端应用程序。
这是React团队给出的推论：首先应该使用框架，在使用框架的前提下不应该使用服务端渲染。
新文件声明
Web 开发前景如何？
官方文档中关于使用该框架的建议肯定会对未来创建新的 React 应用程序的趋势产生深远的影响。
与其花时间去深挖这个框架，我相信更多的人会选择默认使用它。 这意味着未来的Web应用将会变得越来越臃肿，服务器端的处理机制将会被塞进去。
可以看到，虽然使用这个框架也可以创建纯客户端应用程序，但这绝对不是一个常规操作，React团队因此受到了很多批评。
网友们对这些观点特别直言不讳，所以我希望看到官方的回应来澄清人们的负面评论，最好是稍微更新一下文件内容来澄清。
当然，我不认为 React 会因此而失去人气，毕竟它仍然是首选库，并且将继续在包括我自己在内的大多数开发者心目中保持领先地位。
文档中提到的框架的受欢迎程度将会进一步增加，毕竟 React 本身也在使用它（他们的 React.dev 网站使用 Next.js）并开始得到官方文档的推广。
当然，越来越多的应用程序将使用服务器端渲染来创建，所有附加功能（路由等）从一开始就被外部化。
总结
React官方文档是非常好的学习资料，目前所有的争议都无法改变这个基本事实。 新的文档备受期待，现在正式发布终于满足了开发者社区的愿望。
新的文档将会帮助很多人，特别是那些刚刚开始学习 React 的同事。 当然javascript 帮助文档，有经验的开发者也可以作为重要的参考。
总之，新文件确实引起了很多争议和讨论，我们将持续关注事态的进一步发展。
