当前位置: 首页 > Web前端 > vue.js

为什么React默认不推荐Vite?

时间:2023-03-31 16:38:12 vue.js

大家好,我是Kason。在React文档中,构建新React应用程序的首选方法是CRA(create-react-app)。CRA是在2016年推出的,那时候还没有系统的React脚手架工具供大家使用。另外,这是一个官方工具,一推出就受到欢迎。截至目前,CRA仓库已经收获了将近10wstar。但是随着时间的推移,出现了很多优秀的替代品,比如parcel和vite提供的React模板。然而,CRA本身的进展正在放缓。它的最后一次提交要追溯到去年9月8日:另外,CRA对一些流行工具的支持不是很好。比如TailwindCSS文档不推荐CRA:近日,Youtube上拥有10w粉丝的前端网红Theo在React文档仓库发起PR,号召React文档不再默认推荐CRA,而是使用Vite作为构建应用程序的首选。看看围观人数,就可以看出大家对这个敏感问题的关心程度:那么,React团队是如何看待这个问题的呢?他们会将Vite作为构建应用程序的首选吗?这篇文章就是想谈谈Dan(React的核心成员)对这个问题的看法。欢迎加入人类优质前端交流群。CRA的定位是飞。既然CRA是众矢之的,那么首先我们需要了解CRA在React体系下的定位,再看看Vite在这个定位下能否取代前者。CRA诞生的时期(2016年)是SPA(SinglePageApplication)最火的时期。当时他很好的解决了两个痛点:0配置初始化项目这一点不需要过多介绍。执行如下命令后,可以生成一个CSR(客户端渲染)React项目:npxcreate-react-app项目名称集成工具链CRA在react-scripts包下封装了当时的一些最佳工程实践,并平滑排除这些工具的不兼容性。开发人员享受开箱即用的最佳实践,无需担心某些工具升级对项目的影响(CRA会处理)。许多优秀的脚手架工具(如Vite、Parcel)后来都遵循了这种开箱即用的概念。除了以上两点,随着CRA的流行,React团队也将其作为新特性的快速分发渠道,例如:FastRefresh(React的热更新,不丢失组件状态)一系列的lint规则Hooks推出后,依托于CRA巨大的装机量和使用量,这些集成到CRA中的特性可以快速部署到开发者的项目中,从而达到快速提升普及率的目的。试想,如果没有CRA的推广,Hooks的lint规则很难在开发者中有这么高的普及率,Hooks的概念也不会这么快席卷整个前端框架领域。从以上三点来看,Vite完全可以成为比CRA更好的替代品。然而,React团队的想法不止于此。脚手架工具不足CRA虽然开箱即用,但提供的能力并不全面。比如不提供:为什么不提供状态管理方案、路由方案、数据请求方案?因为在CRA发展时期,这些方案还没有形成最佳实践。随着时间的推移,开发人员逐渐想出了解决这些问题的最佳实践。例如请求瀑布问题,考虑以下组件:functionApp(){const[data,update]=useState(null);useEffect(()=>{fetch('http://...').then(res=>update(res.json()))},[])return<子数据={data}/>}App组件只有在渲染完成后才能开始请求数据。这个请求的时间比较晚。如果Child依赖数据Request自己的数据,那么由于App请求的滞后,Child的请求也会滞后。这就是请求瀑布问题。这个问题的一个常见解决方案是将请求数据的逻辑收敛到路由方案中。再比如,随着业务的不断迭代,业务代码越来越大,常见的优化方式就是组件懒加载。然而,手动执行延迟加载通常会产生意想不到的问题。比如页面上有一个图表组件。如果开发者懒加载这个组件,但是这个组件在mount的时候请求数据,就会陷入请求瀑布问题。要彻底解决这个问题,需要配合三类技术方案:数据请求方案(解决数据流向问题)、路由方案(解决数据请求时序问题)、打包方案(解决延迟加载实现的问题)。类似的问题还有很多,比如CSR首屏渲染慢的问题(需要通过SSR解决)。可以看出,CRA在CSR环境中只提供了开箱即用的模板,但是随着项目越来越复杂,CRA对于一些业务细节并没有提供开箱即用的解决方案。从这个角度来看,即使你切换到Vite,你仍然会面临同样的问题。新时代的框架探索了各种常见问题的最佳实践,逐渐出现了一些基于React,融合各种业务问题最佳实践的框架,如Next.js、Remix。其中,Remix是在React-Router(路由方案)的基础上,逐步发展出包含路由、数据请求、渲染的全栈框架。那么,能否将CRA迭代成Next.js、Remix这样的全栈框架,一劳永逸地解决CRA缺乏各种最佳实践的问题呢?React团队认为,这样做需要极高的开发成本,而且随着时代的发展,总会有更多CRA不支持的最佳实践(就像他目前面临的问题),那么CRA总有一天会成为重新开发废弃。因此,该方案不可取。既然这个方案不可取,那么用Vite替换CRA的方案也是不可取的。因为简单的使用Vite并不能解决缺乏最佳实践的问题,那些最佳实践(如路由、数据请求……)必须在此基础上实现,然后又回到开发全栈框架。最终,React团队更倾向于以下方案:使用CRA作为脚手架工具,启动后根据用户的不同场景(如SSR或CSR)推荐不同的框架,然后将CRA作为自下而上的解决方案,不使用框架。并且,在实现上,可以将自下而上方案中的webpack切换到Vite。总结从React团队的思路可以发现,React一直将自己定位为一个状态驱动的UI库。随着时代的发展,单纯使用这个库已经不能满足日常开发的需求,基于React底层使用+实现各种最佳实践模式的框架会越来越流行。最近,Next.js达到了10wstar的成就,成为Github上第14个star仓库,间接印证了这一趋势。回到开头的问题:为什么React不使用Vite作为默认推荐?如果用Vite替代webpack作为CRA的打包工具,未来或许是有可能的。然而,这还不是最重要的问题。如何辅助上层框架更好的为开发者服务,是React团队首要关注的问题。React并没有死,它只是逐渐退居幕后。