前言:工具是次要的。
前言:但是,我们不能放弃追逐好的工具。
前言:而且,我们要勇于抛弃陈旧的工具。
一入前端海,就要找工具。
像HBuilder之流的,就不考虑了。(不买情怀流的帐)
第一时间装了Jetbrains家的WebStorm。
然而用着用着,我就想:为什么我要用它?
其实应该拥抱变化的,为什么就一定要用重型的IDE呢?基本上主流前端工程师都是用文本编辑器+插件的,我为啥不能花这种学习成本呢?各种鸡汤曾灌输我们说:从舒适区里跳出来才能获得成长,不是吗?
那好,从最主流的Sublime、atom、VS Code里面选吧。
- Sublime:老牌。py语言开发的。时光倒流3年我就用它了(当然当时也确实用的它)。强力的插件库。
- VS Code:确实在某视频中见过前端大神在MAC系统里用过这货,也用的挺好,但是微软的东西总让人感觉硬不起来。也许是它名字起的不好吧。
- Atom:插件的强力程度大于等于Sublime。然而,github出品,并且是用nodejs写的。虽然我不会nodejs,但是我就是喜欢nodejs。那么,就它了。
Atom Zhuangbility 流程记录 and gezhong Fly with 插件
好不好用这个问题,自然是谁用谁知道。如果用了发现不好用:要更努力用它,适应它,进而更深度地使用它,然后批判它。
在JS中跳来跳去【同时需要安装 hyperclick插件】
在开发工具中打开命令行,不知道是不是一个好的习惯。如果是,请使用这个插件
格式化代码【用来用去,目前还是webstorm的格式化代码最舒服】
P.S.【2017.08.16补充】弃坑提示:atom的终端(命令行/控制台)插件并不好用。第二名的终端插件直接安不上,第一名的插件终端启动系统后,浏览器中的react开发warning提示没有,而且无法在浏览器中使用redux devtools插件。
规避方式:可以在其他工具中启动系统,不必非得使用atom的控制台插件启动,对日常开发影响不是很大。但是总的来说,atom中开发前端个人感觉还是比在jetbrains家族中舒服一些的。
有了工具,就可以读代码了
editorconfig:有的工程提供了这个文件,我不知道是有意的还是不小心将自动生成的配置文件提交上来了。总的来说,editorconfig约定了编辑器/IDE在这个工程中的一些个性化配置。我们要走读的开源工程中也有这个配置文件,就不展开解读了。
webpack.config.js使用了atool-build扩展,也有可能是dora封装的。鄙人能力有限,因此这个文件就先不展开解读了。基本上是一些less的配置,比较常规吧。
其他读代码部分请见其他文章。本篇主题是说工具。
关于部署
之前我对部署这块认识应该是有个误区。误区是什么就不说了,省的误导别人。
总之:
- 开发时,开一个调试服务就行,不用启动后端,只把前端拉起来就行。数据部分proxy也好,mock也好,开发阶段是真正的前后分离的。
- 部署时,合并部署。一套服务起来,既有前端也有后端。因此,主流实践是前端工程放到整个系统工程目录的frontend目录中。前端人员开发时,只关心这个目录就行。前端build的时候,输出目标文件到整个工程的target目录中去。然后后端工程已启动整个就拉起来了。
因此,在开发阶段和部署阶段,对于工具的选择也可以不同。例如:后端或者整个工程使用idea,前端工程使用atom。
关于开发调试
两个chrome插件一定要装:
- redux devtools。在roadhog的dev模式下可以直接看redux相关的。比如当前state、比如action调用。
- jetbrains IDE Support,可以在intellij或者webstorm中启动JavaScript debug,直接就可以在ide中打断点了。
网友评论