从零到第一个React应用：真实项目实战手记
背景与初心
2019年刚加入团队时，我接到的第一个任务是重构公司内部的一个后台管理系统。原本是用jQuery+模板引擎实现的，代码结构松散、维护困难。面对这种情况，技术负责人建议我们尝试使用React来重新构建。当时我对React几乎一无所知，只知道它很流行，性能还不错。
在接下来的一周里，我一边啃官方文档，一边对照着之前项目的问题，尝试搭建起一个最小可运行的React应用。过程中踩了很多坑，比如版本冲突、依赖管理混乱、组件通信方式选错等，但也正是这些实际问题让我真正理解了React的本质。
今天我就以“**第一次写React应用”**为背景，结合我在真实项目中的经历，带大家从安装开始一步步走到第一个可用的应用，让你不仅能跑起来，还能写出清晰、可维护的代码。
遇到的第一个问题：怎么开始？
刚开始接触React，最常听到一句话就是：“你可以用React来开发单页应用（SPA）”。那什么是单页应用？和传统的前后端不分离有什么区别？
其实一开始我也一头雾水。直到有一天，我打开了Facebook的开发者页面，看到了他们在React DevTools里实时更新组件状态的效果，才突然有点感觉。
但问题来了，如何快速搭建一个可以运行的React环境呢？我搜索了一下，网上常见的方法是：
- 手动配置webpack + Babel
- 使用Create React App（CRA）
- 使用Vite等新工具
我当时的第一反应是想手动配置一下webpack，毕竟学技术嘛，不折腾一下总觉得没掌握到位。但后来同事提醒我：你的目标不是成为webpack专家，而是把业务需求做出来。
于是，我选择了Create React App。这一步看起来简单，但我依然遇到了一些小麻烦，比如Node.js版本太低、npm权限问题、全局模块未安装等，都耽误了不少时间。
教训总结：新手上路建议先不要自己造轮子，先借助脚手架工具快速入门。熟悉后，再深入了解底层原理。
第一次写React组件：函数式VS类组件？
当环境跑通之后，我就开始写第一个组件了。那时候的文档中对类组件介绍得比较多，社区里也有不少人推崇面向对象的方式，所以我很自然地用了类组件来写。
写了一个简单的按钮组件，然后把它放在App.js里面引用。看起来没问题，但很快我就遇到了一个问题：多个组件之间的状态共享怎么做？
比如有一个父组件控制按钮的开关状态，子组件需要根据这个状态显示不同的UI，这时候我尝试用props传值，结果发现越来越复杂。
这时候我才意识到，React的核心理念之一其实是数据驱动视图，而不是像jQuery那样直接操作DOM。状态变了，UI自动更新。
于是我开始了解Hook API（当时刚刚发布不久），特别是useState和useEffect这两个核心Hooks。当我改用函数组件重写原来的功能后，代码变得更简洁，逻辑也更清晰了。
经验总结：现在推荐新手直接从函数式组件+Hook开始学习，不仅语法更简洁，也更符合现代React的主流方向。
构建第一个完整的小应用：Todo List
为了加深理解，我决定做一个Todo List应用作为练手项目。功能包括：
- 添加任务
- 删除任务
- 切换任务完成状态
- 统计已完成/待办数量
在这个项目中，我遇到的第一个挑战是如何管理多个组件的状态。最初的思路是每个子组件自己保存是否完成的状态，后来发现这样根本无法进行统一管理。
于是我引入了一个状态管理的概念——虽然还没学到Redux，但通过将状态提升到父组件中，配合回调函数传递事件，实现了状态集中管理。这让我第一次体会到React的数据流向之美。
另一个挑战是表单输入绑定。我想当然地写了类似下面的代码：
<input type="text" value={this.state.text} />
结果发现输入框不能修改！原来是忘了给input加上onChange事件更新state。这让我明白，在React中，一切都是可控组件，必须显式处理状态变更。
这个问题虽然很小，但在实际工作中非常常见。尤其是刚开始用React的时候，很多人都会掉进“双向绑定”的思维惯性陷阱中。
用户体验细节：别忽视交互反馈
写完基本功能后，我兴奋地把Demo分享给产品经理看。他问了一句：“点击删除按钮的时候能有个提示吗？” 我说可以，随手加了个window.confirm()弹窗。
结果他说：“用户点删除的时候，能不能先高亮一下？或者动画提示一下？”
这让我开始思考：前端不仅仅是实现功能，更要关注用户体验和交互细节。
于是我做了几个改进：
- 删除前添加CSS hover效果
- 点击删除时增加一个淡出动画
- 状态变化时添加过渡效果
这些细节虽然小，但确实提升了整体质感，用户反馈也更好了。
浏览器兼容性和性能优化：别被忽略的部分
项目完成后上线了一段时间，有同事反映在IE11下报错。我打开调试工具一看，原来是我用到了ES6的一些特性，比如箭头函数、解构赋值等，而IE根本不支持这些语法。
于是我们引入了Babel来转译JSX和ES6代码，并且加上polyfill补丁。这段经历让我意识到：
兼容性不是可选项，而是必须要考虑的基础问题。
此外，还有一点就是首屏加载速度。刚开始用CRA默认配置打包，整个app.js文件高达3MB，加载速度明显变慢。
后来我们做了几件事来优化：
- 启用splitChunks分块加载
- 对图片资源进行压缩
- 使用React.lazy延迟加载非首屏组件
- 加入路由懒加载
优化后，首次加载从3秒降至0.8秒以内，用户体验明显提升。
小插曲：调试过程中的那些“坑”事
还记得有一次，我在写一个列表组件的时候，数据明明更新了，但视图没有刷新。检查了半天，才发现是因为直接修改了state里的数组，比如：
const todos = [...this.state.todos];
todos[index].completed = true;
this.setState({ todos });
这样写在React中是有问题的，因为它不会触发深度比较机制。正确的做法应该是创建一个全新的数组，并替换旧数组。
还有一次，我在useEffect里忘记加依赖项，导致闭包捕获的state还是旧值，出现奇怪的bug。这些问题初学者很容易踩坑。
所以，我强烈推荐使用React DevTools和Chrome Debugger辅助开发，它们能帮助你查看组件树结构、状态变化、以及Hook调用链等信息，极大提高排查效率。
最终成果与收获
那个小小的Todo List练手项目，后来成为了我进入React世界的敲门砖。它让我理解了React的基本原理、组件设计方式、状态管理和交互优化方法。
更重要的是，它让我认识到：
React不仅仅是一个框架，它背后是一整套工程化的思维方式。
随着后续项目的深入，我陆续掌握了React Router、Axios异步请求、Context API跨层级传值、以及状态管理方案如Redux Toolkit，甚至参与了基于Next.js的服务端渲染项目。
给读者的几点建议
如果你正准备学习React，以下是我的一些建议：
✅ 1. 先跑通最小项目，不要一开始就追求完美架构
很多人一开始就想着要搭一个完美的项目结构，结果还没开始写功能就卡在目录结构设计上了。建议先完成一个基础项目再说。
✅ 2. 多动手，少看“概念视频”
React不像数学公式那样可以通过背诵理解。它的本质在于“状态驱动”，这种思想只有在实际编码中才会慢慢领悟。多做一些小项目，哪怕是一个天气预报、一个购物车也好。
✅ 3. 学会善用浏览器和调试工具
Chrome DevTools + React DevTools是你的好朋友。学会用它们查看组件生命周期、Hook调用、状态变化等，能节省你大量调试时间。
✅ 4. 不要迷信新技术，先打好基础
现在有很多新框架，比如Solid.js、Svelte等，但它们背后的很多理念其实都源自React。先把React吃透，再去研究其他工具也不迟。
✅ 5. 多看源码、阅读开源项目
GitHub上有大量的优质React项目，像Material UI、React Query、Formik等库的源码，值得细细品味。即使看不懂全部也没关系，挑一段看得懂的地方细读也能学到很多东西。
结语：写在最后的一些感悟
回望我第一次写React的那段时光，虽然走了一些弯路，但回头看都是宝贵的积累。现在的我已经能够独立负责前端模块的设计与实现，也经常参与团队的技术评审工作。
React这条路看似简单，实则充满细节。它不只是一个前端框架，它是一种看待界面构建的新视角，也是一种不断提升的工程能力。
如果你正在这条路上，请相信——你并不孤单。
欢迎你在评论区留言，我们可以一起交流学习经验，分享更多前端成长故事 😊
评论 0