大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
这篇文章主要介绍“React不将Vite作为构建应用的首选原因是什么”,在日常操作中,相信很多人在React不将Vite作为构建应用的首选原因是什么问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”React不将Vite作为构建应用的首选原因是什么”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
在晋城等地区,都构建了全面的区域性战略布局,加强发展的系统性、市场前瞻性、产品创新能力,以专注、极致的服务理念,为客户提供成都做网站、网站设计 网站设计制作按需网站开发,公司网站建设,企业网站建设,成都品牌网站建设,全网营销推广,外贸网站建设,晋城网站建设费用合理。
在React
文档中,对于构建新的React
应用,首推的方式是CRA
(create-react-app)。
CRA
推出于2016年,彼时还没有成体系的React
脚手架工具供大家使用,再加上这是官方工具,一经推出就受到了欢迎。截止当前,CRA
仓库已经收获快10wstar
。
但是,随着时间的推移,出现了很多优秀的替代品,比如parcel
、vite
提供的React
模版。而CRA
本身的进步速度却在放缓,其上一次提交要追溯到去年9月8日。此外,CRA
对一些流行工具的支持也不是很好,比如在TailwindCSS
文档中就不推荐使用CRA
:
既然众矢之的是CRA
,那么首先我们需要明白CRA
在React
体系下的定位,再来看看Vite
能否在这个定位下取代前者。
CRA
诞生的时期(2016年),是SPA
(单页应用)最火热的时期。在当时,他很好的解决了两个痛点:
这点不用过多介绍,执行如下命令后就能生成一个CSR
(客户端渲染)的React
项目:
npx create-react-app 项目名复制代码
CRA
将当时的一些工程化最佳实践都封装在react-scripts
包下,并抹平这些工具不兼容的地方。
开发者既享受了开箱即用的最佳实践,又不用担心某些工具升级后对项目造成的影响(CRA
会处理)。
后来的很多优秀脚手架工具(比如Vite
、Parcel
),也都沿用了这种开箱即用的理念。
除了以上两点,随着CRA
的走红,React
团队还将他作为新特性的快速分发渠道,比如:
Fast Refresh
(针对React
的热更新,不会丢失组件状态)
Hooks
推出后的一系列lint
规则
依托CRA
庞大的装机量与使用量,这些集成到CRA
的特性可以快速部署到开发者的项目中,达到快速提高普及率的目的。
试想,如果没有CRA
的推动,Hooks
的lint
规则很难在开发者中有这么高普及率,Hooks
的理念也就不会这么快席卷整个前端框架领域。
从以上三点来看,Vite
完全可以成为比CRA
性能更优的替代品。
但是,React
团队的考量不仅如此。
虽然CRA
开箱即用,但他提供的能力并不全面,比如他并不提供:
状态管理方案
路由方案
数据请求方案
为什么不提供呢?因为在CRA
发展的时期,这些方案还未形成最佳实践。
随着时间发展,开发者逐渐摸索出解决这些问题的最佳实践。比如请求瀑布问题,考虑如下组件:
function App() { const [data, update] = useState(null); useEffect(() => { fetch('http://...').then(res => update(res.json()))
}, [])
return
只有当App
组件渲染后才能开始请求数据,这个请求时机是比较滞后的,如果Child
依赖data
来请求自己的数据,那么由于App
请求的滞后导致Child
的请求也滞后了,这就是请求瀑布问题。
这个问题常见的解决方法是 —— 将请求数据的逻辑收敛到路由方案中。
再比如,随着业务不断迭代,业务代码体积越来越大,常见的优化手段是懒加载组件。
但是,手动执行懒加载常常会产生意料之外的问题。比如,页面中有个图表组件
,如果开发者懒加载了这个组件,但是该组件在on mount
时请求数据,这又会陷入请求瀑布问题。
要彻底解决这个问题,需要配合3类技术方案:
数据请求方案(解决数据流向问题)
路由方案(解决数据请求时机问题)
打包方案(解决懒加载的实现问题)
类似的问题还有很多,比如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不将Vite作为构建应用的首选原因是什么”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!