我进入项目的时候已经是在项目的后期了，所以项目前期的代码规范、接口集成，都没有参与。因此有关集成的东西都不是特别了解。且状态的管理使用的是redux，之前完全没有接触过的一个管理状态的库。
在使用react开发的时候，个人觉得前期的规划是非常重要的。规划好通用的component。在common的component内最好是不要加入过多的判断逻辑，因为会大大减少组件的重用性。在后期组件重构的过程中，最大的心得体会就是尽量在组件内部暴露出足够的props字段来控制组件，而减少在组件内部的hard code。其次，在当时做项目的时候react-native的官方文档暴露出来的方法并不是非常多。导致这个跨平台的过程其实是非常痛苦的。虽然react-native是可以兼容iOS和Android，但是同样的组件在两个平台上的显示上差异非常的大。几个像素的差异是躲不过ux的法眼的。所以往往会借助react-native暴露出来的一个方法 Platform 来判断一次。所以有时候样式或逻辑代码不得不出现多次。但综合相比较，比为了适配iOS写object-c或者为了适配android写Java要来的快速很多。
作为一个萌新，初期做校验的时候非常喜欢正则… ||_||，后来发现很多js原生的方法其实就可以完成某些校验！点个赞。但是这里需要引出lodash了。因为lodash可以完美解决兼容IE的问题。其次，语义化比较明显，之后再改动代码的时候，是非常方便的，如果直接写正则，后来的人可能不太能明白这个正则是做那部分的校验。
其次最开始的时候，只想着实现功能，完全忽略了代码的规范性。回来经过mentor的纠正，发现很多逻辑判断代码都不要带到组件内部去实现。组件是尽量干净、尽量通过向外部暴露props去控制的。逻辑放在组件的外层。
在做APP端的开发的时候，提出需要等宽字体的支持，查了很久用了monospace。但是使用了发现这个字体在安卓上间隔非常的宽松，宽松到让人绝望…后来用了另一个等宽字体Roboto
关于package-lock.json的意义是什么呢？查询资料之后发现就是锁定安装时的包的版本号，并且需要上传到git，以保证其他人在npm install时大家的依赖能保证一致。而package.json只能锁定大版本，也就是版本号的第一位，并不能锁定后面的小版本，这也是为了稳定性考虑。ps：如果想要跟新package-lock.json内的版本号在安装的时候npm install xxx@x.y.z加上版本号，就会自动更新到package-lock.json里。
在渲染有分页table的时候，采取懒加载的方式。每次只取这个范围内的几条数据，不一口气把所有的数据取回来，这样会优化性能。
在使用expo的时候发现expo是一个很好的调试工具。可以连接到浏览器控制台去debug，也可以选择样式去看每个元素的样式。
我进入项目的时候已经是项目的尾声了，工作量也相对较小。但是还是有很多学习到的地方。特别是摸清楚数据流向是非常关键的一个步骤，只有摸清楚了这个，才能更好的处理前台的逻辑。按照业务逻辑展示数据，修改数据，创建数据大概就是前端的意义吧。