摘要：好，你用就用吧，各种问题自己也不会看文档问谷歌，成天怨声载道的不得不吐槽一下现在的年轻人。为什么使用有关和的纠结历史可以去谷歌一下，此处不再啰嗦最根本的原因就是对的支持更好，更新和维护也更勤快。
Tips on Ember 2 对我来说是没什么计划性的写作，我只是把它当做是每天工作的总结日志，一个很重要的目的是为团队做一些技术事务的整理，以帮助一些新人快速成长起来。如果有些内容不能满足各位看官的胃口，提前说声抱歉并且请不要担心，随着项目的逐渐开展，好戏会在后头。
上一篇我提到了暂时使用 Ember.GlimmerComponent 取代 Ember.Component 的事情，虽然有效但是却不得不改变编写 Component 的接口，着实挺烦的。其实我们可以直接替换掉旧的 |0e610412be5446ac40810dba92904e3c2| 便好，于是我加了很简单的一句：
// 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］，然后针对项目里的各种目录打一些必要的标记；如图：
简要解释一下这三个标记的作用：
Tests：标记测试文件所在的根路径；对于很多测试框架来说这是 Webstorm 给它们指示测试文件位置的标志，然而由于并不支持 Ember CLI 所以没什么鸟用——当然你可以尝试绕过 Ember CLI 直接配置基于 QUnit 的测试环境，难～
Excluded：该标记作用下的文件夹会被 Webstorm 内部的各种机制排除在外，比如说代码补全、状态监视（版本控制）、项目结构解析（常用于重构等）等等；主要的作用就是提速——你把 tmp/ 去掉这个标记试试看！
Resource Root：标记静态资源的位置；之后在代码内但凡出现相对路径的资源索引，都会从这里面来找，比如说 HTML 里面的 src 属性和 CSS 里面的 url() 等等……
OK，后面两个其实是调整 Webstorm 性能与功能的关键平衡点，标记的过少会导致很多智能特性发挥不了用处，反之则会严重降低 IDE 的运行性能。我 09 年的老爷机通过合理配置（和上图那个 Demo 不完全一样，需要自己摸索）之后跑得比最新的 MBP 还顺畅我会随便乱讲？
语言与框架 Javascript目前版本的 Ember CLI 已经全面支持 ES6 了，所以这里的选择是理所当然的；
严格模式不用选，因为 Ember CLI 创建的代码都是基于 ES6 Modules 的，默认都是严格模式，不需要 IDE 检查；
最后一个选项决定了自动代码补全结果的丰富程度，不选会给你找出更多的补全项，但也意味着杂乱和性能损耗。
Node.js 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 它们，这就派上用场了。
Libraries为什么使用 io.js？有关 node.js 和 io.js 的纠结历史可以去谷歌一下，此处不再啰嗦；最根本的原因就是 io.js 对 ES6 的支持更好，更新和维护也更勤快。好消息是不久以后当 io.js 进入 v4 的时候，node.js 和 io.js 将再次合并，从此以后将只有一个 node.js v4 了。
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，非常便利。这些都可以在这个界面里搜索和安装。
JSHintEmber CLI 集成了代码质量控制工具 JSHint，Webstorm 也有很棒的内部支持，不过配置要跟着上图来，否则是没有用的。
Templates这些是关于模版引擎的支持，现在 Ember 已经使用了全新的模版引擎：HTMLBars，目前没什么 IDE 有完整支持的，最贴近的还是 Handlebars 插件（可能需要自行安装或开启，见［Preferences -> Plugins］）。
前两个选项完全是看个人偏好
第三个不要选！选了之后会使用内置的格式控制，但实际上并没有针对 Handlebars 的格式控制调整，因此据我观察还是复用了 HTML 那一套，然而并不好用；Ember CLI 继承了 EditorConfig（Webstorm 有对应的插件支持），因此还是交给插件自己去控制，这样可以获得相对漂亮的代码格式控制
第四个选项其实没啥用处（在 Ember 项目里全是 .hbs，没有 .html 什么事情），选不选都一样
最后的注释还是选择 Handlebars 风格比较好
BowerBower 的支持配置很简单，路径选对就是了。
就这些，Webstorm 对 Ember 和 Ember CLI 的支持也就这样了，真心很有限，感觉有点对不起它的名声呀，我觉得你们大家还是投入到 Vim 的怀抱来吧！
最后奉送一个 tip，在 v2.3 的 Routable Components 到来之前有用的：
修改 toplevel component/view 的方法什么是 toplevel component/view 呢？就是应用初始化后在 标签里插入的第一个 DOM 元素，它通常是这样的：
...
它看起来和其他的 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 下面，否则是找不到的。
原文首发于 Ruby China 社区，转载请注明。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/85964.html
摘要：今天这篇主要讲讲里关于样式开发的一些前期准备工作，主要是和。总的来说就不要再用了，又大又笨而且连亲爹都准备放弃它了，未来将是小快灵组件协同工作的大趋势，就是可以用来替代的组件库。 今天这篇主要讲讲 Ember CLI 里关于样式开发的一些前期准备工作，主要是 Sass 和 Bootstrap。 Ember Addons 是寻找各种组件的绝佳场所，下文将要介绍的一些都可以在这里找到，没事...
摘要：警告版本是很不稳定的，并不推荐使用于要上线的应用。如果你要尝试新的特性，要么是新建一个测试用的，要么是你的应用离正式上线还早并且你和你的团队折腾得起。在此功能正式发布之后应该是不需要这段补丁代码的，目前来说也不会影响使用。 Ruby China 的朋友大概都知道我很喜欢 Ember，然而我用 Ember 的经历其实远比不上 Angular 那么丰富（Ember 业余爱好，Angular...
摘要：如果说传统的前端开发是以页面为中心来入手的话，那么现代的应用开发就是以状态为中心来着手设计和开发的。初步分析路由是怎么管理状态的复杂的话题简单说在中，应用的每一个可能的状态都是通过体现的。 引子 SPA（单页面应用）的核心是什么？ 自该类型应用诞生以来我最多思考的问题就是这个。现在前端 SPA 框架满天飞，许多不是框架的也被称作框架，究竟有什么代表性的层（layer）能让一个系统称得上...
摘要：因为组件的存在范围被限制在以内，这就是这种机制目前存在的意义所在。组件都是可以传递参数或外部作用域的，利用此机制进行判断来执行可选行为，这是对用户友好的举措。 这一篇还是一个简单的例子所引发的思考。 你看，如今的框架和库，无论规模大小功能多少，它们在本质上都朝着组件化的思路快速演进着。Angular 有 directives，Angular 2应该也还是这个叫法；Ember 从 Vie...
摘要：最近公司主项目用到了，虽然当前前端业内推崇但是接触到过后，被的工程化震撼到了，相比于，前者算是一个而后者更应该算是一个框架，这篇文章的主题不打算完整的介绍一下，出于公司需要建一个公共组件库的目的，这里介绍一下相关的技术细节为什么需要 最近公司主项目用到了 ember + ember-cli，虽然当前前端业内推崇 react , 但是接触到 ember-cli 过后，被 ember-cl...
阅读 499·2021-10-14 09:42
阅读 1756·2021-09-22 15:04
阅读 1361·2019-08-30 12:44
阅读 2032·2019-08-29 13:29
阅读 2604·2019-08-29 12:51
阅读 424·2019-08-26 18:18
阅读 585·2019-08-26 13:43
阅读 2690·2019-08-26 13:38
