原文哪Russ
本文编译:胡子大哈翻译原文:http://huziketang.com/blog/posts/detail& # 63; postId=58 e83f01a58c240ae35bb8e1
英文连接:11的经验教训作为反应承包商转载请注明出处,保留原文链接以及作者信息
一开始反应在路上摸爬滚打的时候,不知道该寻找些什么,但是这些年来,回头总结经验才发现,要找的已经在脑子里了。下面是我自己在学习反应历程的一些关键点,以及我的一些背景情况。
<李>我已经写了18年的代码,其中13年是全职专业的老司机了,李 <李>其中6年时间都专注于Flash开发;李 <李>直到史蒂夫·乔布斯的公开信表示不支持Flash;李 <李>我刷过HTML、CSS和javascript这几个技能点,李 <李>曾经在主流JavaScript框架的研究上纠结了很久,当时感觉它们把大量的逻辑都隐藏在了背后,李 <李>辞职开始外包生活,主要做原型;李 <李>看了很多反应演示;李 <李> 2015年10月,正式开始反应项目生涯并且爱上了它,李 <李> 2016年1月,改了我在LinkedIn上的标题:反应开发者。
接下来是我所总结的一些经验,希望能对你有所帮助。
<编辑id=" 1 - "> 1。多个简单组件比一个高度定制化组件要好改变反应组件行为依赖于你传递的道具,这是个很有用的功能。在项目初期就养成一个好的编程习惯对未来很有好处:创建一些通用组件,使其在其他地方也可以使用。
当你开始了项目以后,对于一个组件你可能会不断地扩展这个组件的使用外延。一段时间以后你会发现,你会疲于修复bug,在一场景下修复好以后,又发现在场景B和场景C下又发现了错误。
我的建议:如果一个组合组件导致了错误,那么把它分解成若干个简单组件,即便代码重复也值得。
<编辑id=" 2-bug-issue-pull-request "> 2。如果你发现了库中有错误,尽量提问题和拉请求只要你使用反应,就一定会用到开源软件,不论是反应核还多是1000个可用的NPM模块。如果你发现了库中有错误,那就提问题上去。更好的情况是,如果你修复了一个bug,一定要提拉请求把修复的代码整合进去,因为使用这个库并且遇到错误的并不只是你一个人,这样做会使整个生态变得更好。
我的建议:回馈社区,即便你只是修正了文档中的拼写错误也好。
<编辑id=" 3-build-react——“> 3。首先完成一次构建过程,然后再写反应代码一直编辑我知道这并不是一个常见的场景,但是我就遇到过,当我开始一个外包项目并且开始建造的时候,发现有一些依赖编译的包不存在。进而才发现实际上这个反应是用于一个骨干项目中的。在主干中实现反应组件其实非常简单,使用回来的可以在这两个之间进行通信。它们之间的通信必须要通过Browserify或者Webpack编译到一起才可以。
我的建议:如果在一个现有的项目中应用反应,首先用Browserify或者Webpack走一遍构建过程比较好。
<编辑id=" 4-svg-d3 "> 4。对于简单的数据可视化,原生SVG祝辞=D3D3在数据可视化方面做的非常棒,但是如果你只是要做一些简单的数据可视化,那么渲染原生SVG就可以满足你的工作需求了。
我的建议:学习一些SVG基础,在你需要更复杂功能之前这就够了.Youtube的前端中心频道前几天刚好播放了关于SVG的节目,值得一看。
<编辑id=" 5 - "> 5。如果你只有两周的项目期限,保持功能精简如果你要做的工作只是渲染,那么的反应和React-DOM就足够了。
回来的的处理很耗费时间和精力,它对于处理大项目中的多层界面很有用。但是如果你的项目很简单的话,那么通过传递道具和回调就好了,不必要使用回来的。
我的建议:模板项目是非常有用的,但是如果你想保持项目精简的话,从反应和React-DOM开始是一个很好的选择。
<编辑id=" 6-css——“> 6。单独依赖于CSS动画来移动元素会很慢我没有办法精确地告诉你什么时候会看到帧速率显著下降,也许是30个元素的时候,也许是300个元素的时候。但是可以告诉以一些对你有帮助的经验,充分利用反应的虚拟DOM,并且保证只在需要的时候进行渲染和重渲染。
就是说只渲染那些在视图窗口中可见的组件。
我的建议:在低配机器上进行测试,同时还要测试边界数据来看一下你的程序在受限的情况下表现如何。
作为老司机使用反应总结的11个经验教训
