資訊專欄INFORMATION COLUMN
摘要：好，你用就用吧，各種問題自己也不會看文檔問谷歌，成天怨聲載道的不得不吐槽一下現在的年輕人。為什么使用有關和的糾結歷史可以去谷歌一下，此處不再啰嗦最根本的原因就是對的支持更好，更新和維護也更勤快。
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 社區，轉載請注明。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/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...
閱讀 712·2021-10-14 09:42
閱讀 1966·2021-09-22 15:04
閱讀 1571·2019-08-30 12:44
閱讀 2134·2019-08-29 13:29
閱讀 2730·2019-08-29 12:51
閱讀 542·2019-08-26 18:18
閱讀 697·2019-08-26 13:43
閱讀 2803·2019-08-26 13:38
