EmberJS [Tips on Ember 2] Ember CLI with Webstorm & top level component/view

nightire · 2015年09月02日 · 最后由 nightire 回复于 2015年09月05日 · 4470 次阅读

Tips on Ember 2 对我来说是没什么计划性的写作,我只是把它当做是每天工作的总结日志,一个很重要的目的是为团队做一些技术事务的整理,以帮助一些新人快速成长起来。如果有些内容不能满足各位看官的胃口,提前说声抱歉并且请不要担心,随着项目的逐渐开展,好戏会在后头。

补充上篇的内容

上一篇我提到了暂时使用 Ember.GlimmerComponent 取代 Ember.Component 的事情,虽然有效但是却不得不改变编写 Component 的接口,着实挺烦的。其实我们可以直接替换掉旧的 Ember.Component 便好,于是我加了很简单的一句:

// app/app.js
// ...

Ember.MODEL_FACTORY_INJECTIONS = true

Ember.GlimmerComponent.reopenClass({
  isComponentFactory: true
})
Ember.Component = Ember.GlimmerComponent

App = Ember.Application.extend({...})

这样你 Component 该怎么写就怎么写,不用再改了。

不喜欢 Ember 和 Ember CLI 的 Webstorm

我是 Vim 党,很少折腾复杂笨重的 IDEs,然而小伙伴们不高兴了,纷纷表示 Vim 太难学还是要用 Webstorm(也有选择 Sublime/Atom 的,由于配置比较简单,略过)。好,你用就用吧,各种问题自己也不会看文档问谷歌,成天怨声载道的(不得不吐槽一下现在的年轻人……)。没办法,我自己来一遍配置,填掉所有的坑!

Webstorm 以前用 Angular 的时候也试过,总体上还行,代码补全比较优秀,就是稍微有点慢;然而我是那种不依赖自动补全,就是喜欢手打的类型,所以还是轻便迅捷的 Editor 合我的胃口。这次换成搭配 Ember 和 Ember CLI 了,好家伙~各种小问题层出不穷,官方就是不支持你也没有办法,最终我只能整理一下力所能及的配置过程了——

项目特定

文件夹标记

在 Webstorm 导入 Ember CLI 创建好的项目之后,打开[Preferences -> Project -> Directories],然后针对项目里的各种目录打一些必要的标记;如图:

directories

简要解释一下这三个标记的作用:

  • Tests:标记测试文件所在的根路径;对于很多测试框架来说这是 Webstorm 给它们指示测试文件位置的标志,然而由于并不支持 Ember CLI 所以没什么鸟用——当然你可以尝试绕过 Ember CLI 直接配置基于 QUnit 的测试环境,难~
  • Excluded:该标记作用下的文件夹会被 Webstorm 内部的各种机制排除在外,比如说代码补全、状态监视(版本控制)、项目结构解析(常用于重构等)等等;主要的作用就是提速——你把 tmp/ 去掉这个标记试试看!
  • Resource Root:标记静态资源的位置;之后在代码内但凡出现相对路径的资源索引,都会从这里面来找,比如说 HTML 里面的 src 属性和 CSS 里面的 url() 等等……

OK,后面两个其实是调整 Webstorm 性能与功能的关键平衡点,标记的过少会导致很多智能特性发挥不了用处,反之则会严重降低 IDE 的运行性能。我 09 年的老爷机通过合理配置(和上图那个 Demo 不完全一样,需要自己摸索)之后跑得比最新的 MBP 还顺畅我会随便乱讲?

语言与框架

Javascript

javascript

  • 目前版本的 Ember CLI 已经全面支持 ES6 了,所以这里的选择是理所当然的;
  • 严格模式不用选,因为 Ember CLI 创建的代码都是基于 ES6 Modules 的,默认都是严格模式,不需要 IDE 检查;
  • 最后一个选项决定了自动代码补全结果的丰富程度,不选会给你找出更多的补全项,但也意味着杂乱和性能损耗。

Node.js and NPM

node-and-npm

  • 先跳到 node.js 和 npm 的配置,由于我们统一使用的是 io.js,所以如上图所示对应的路径。
  • 以前呢,io.js 的 sources 是不能在这里获取到的,最近的版本应该是修正了这个问题。不过下载下来的 sources 被命名为 Node.js v3.2.0 Core Modules 由于我手动改了它的名字(后面会讲到),所以上图里看起来还是未下载和配置 sources 的样子。
    • 这个 sources 有什么用?当你开发 node.js/io.js 模块时,如果能有对核心库的代码补全、分析、调试、文档等功能那自然是很爽。但是 node.js/io.js 把核心库都封装在了二进制运行命令中,IDE 无法直接获取到,因此这些 sources 就是用来做上述功能的。
    • 对于 Ember 应用程序开发来说,以上是非必需的,没有配置也没什么影响。只不过 Ember CLI 是工作于 node.js/io.js 环境下的,如果你经常需要看相关模块的代码,或是 debugging 它们,这就派上用场了。

为什么使用 io.js?有关 node.js 和 io.js 的纠结历史可以去谷歌一下,此处不再啰嗦;最根本的原因就是 io.js 对 ES6 的支持更好,更新和维护也更勤快。好消息是不久以后当 io.js 进入 v4 的时候,node.js 和 io.js 将再次合并,从此以后将只有一个 node.js v4 了。

Libraries

libraries

node.js 和 npm 那边配置好以后呢,在这里会出现 Node.js v3.2.0 Core Modules,如上图所示我已经把它更名为 io.js v3.2.0 Core Modules 了。最上面那个 ember-DefinitelyTyped 是 TypeScript 社区提供的 API Stubs,有助于快速的代码补全提示。TS Community 还提供了大量的 JS 库或框架的 API Stubs,非常便利。这些都可以在这个界面里搜索和安装。

JSHint

jshint

Ember CLI 集成了代码质量控制工具 JSHint,Webstorm 也有很棒的内部支持,不过配置要跟着上图来,否则是没有用的。

Templates

templates

这些是关于模版引擎的支持,现在 Ember 已经使用了全新的模版引擎:HTMLBars,目前没什么 IDE 有完整支持的,最贴近的还是 Handlebars 插件(可能需要自行安装或开启,见[Preferences -> Plugins])。

  • 前两个选项完全是看个人偏好
  • 第三个不要选!选了之后会使用内置的格式控制,但实际上并没有针对 Handlebars 的格式控制调整,因此据我观察还是复用了 HTML 那一套,然而并不好用;Ember CLI 继承了 EditorConfig(Webstorm 有对应的插件支持),因此还是交给插件自己去控制,这样可以获得相对漂亮的代码格式控制
  • 第四个选项其实没啥用处(在 Ember 项目里全是 .hbs,没有 .html 什么事情),选不选都一样
  • 最后的注释还是选择 Handlebars 风格比较好

Bower

bower

Bower 的支持配置很简单,路径选对就是了。


就这些,Webstorm 对 Ember 和 Ember CLI 的支持也就这样了,真心很有限,感觉有点对不起它的名声呀,我觉得你们大家还是投入到 Vim 的怀抱来吧!

最后奉送一个 tip,在 v2.3 的 Routable Components 到来之前有用的:

修改 toplevel component/view 的方法

什么是 toplevel component/view 呢?就是应用初始化后在 <body> 标签里插入的第一个 DOM 元素,它通常是这样的:

<body>
  <div id="ember-xxx" class="ember-view">...</div>
</body>

它看起来和其他的 components 差不多,唯一的问题是如果你想改它的 tagName/elementId/classNames 等属性的时候该怎么办?

创建一个 ApplicationComponent?没用……创建一个 ApplicationView?对不起,View 已经没了……

在 Routable Components 出来之前(其实这就是一个典型的 Routable Component),唯一修改它的办法其实是创建一个叫 ApplicationView 的 Component——啥意思?看下面:

$ ember generate view application

然后编辑 app/views/application.js

import Ember from 'ember'

export default Ember.Component.extend({
    tagName: 'main',
    classNames: ['application']
    ...
})

如上,它是一个 Component,但要保存在 app/views 下面,否则是找不到的。

共收到 4 条回复

高质高产啊!你也用不带 ; 的代码风格?如果这样,可以再加上 tailing comma(给每个 object 和 array 的最后一个元素加上 ,)。这样犯错概率更少一点,Git commit 也好读一些。反正 Babel.js 编译时会自动去掉末尾的 ,

#1楼 @darkbaby123 嗯,有些轻微强迫症,如果要用 ; 我一定会倾向于所有 required 的地方一定加,所有 optional 的地方一定不加,这样一来总是把一点点的碎片时间浪费在代码格式化里……所以索性一概不用。回到 Ember 以后,Ember CLI generate 的 文件都有 ;,着实让我纠结了一阵,哈哈。

我使用 RubyMine 来开发 ember.js + rails =.=
我压根就会将自动补全给关掉, 然后需要的时候再手动巧一下快捷键.

很多框架的支持在 jetbrains 的产品基础平台上基本都是通过插件集成的, 插件的质量我用过的官方自己支持的是真的高质量. 比如 scala, Angularjs, Nodejs, ideavim, Handlebars 的插件~

用 RubyMine 的最大原因是, 被 jetbrains 的产品养成了快捷键,集成的工具的使用习惯以后, 换到任何其他的工具都觉得不顺手, 写东西不够快...

#3楼 @wppurking 其实自动补全我并不是很看重,因为我都是习惯手打的,上面的布置主要还是为了依赖关系之间相互跳转方便的,很多人都不会配置这个,找个源码看得我费劲儿啊。

其实不依赖 IDE 的补全机制的话,还是用更轻量的编辑器来得痛快。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册