Ember 資源和故障排除
我們的最後一篇 Ember 文章為您提供了一系列資源,您可以利用這些資源進一步學習,此外還有一些有用的故障排除和其他資訊。
| 預備知識 |
至少,建議您熟悉核心 HTML、CSS 和 JavaScript 語言,並瞭解 終端/命令列。 Ember 大量使用現代 JavaScript 特性(如類、模組等),因此深入理解這些特性將非常有益。 |
|---|---|
| 目標 | 提供更多資源連結和故障排除資訊。 |
更多資源
-
Ember.JS Discord 伺服器 — 一個論壇/聊天伺服器,您可以在其中結識 Ember 社群成員、尋求幫助並幫助他人!
一般故障排除、陷阱和誤解
這遠不是一個詳盡的列表,但它是編寫本文時(最新更新,2020 年 5 月)出現的一些內容的列表。
如何除錯框架中發生的事情?
對於框架特定的事項,有 ember-inspector 附加元件,它允許檢查
- 路由和控制器
- 元件
- 服務
- Promises
- 資料(即來自遠端 API — 預設來自 ember-data)
- 廢棄資訊
- 渲染效能
對於一般的 JavaScript 除錯,請檢視我們的 JavaScript 除錯指南以及與瀏覽器的其他除錯工具的互動。在任何預設的 Ember 專案中,都會有兩個主要的 JavaScript 檔案:vendor.js 和 {app-name}.js。這兩個檔案都帶有 sourcemap,因此當您開啟 vendor.js 或 {app-name}.js 搜尋相關程式碼時,放置偵錯程式後,sourcemap 將被載入,並且斷點將放置在預轉譯程式碼中,以便更容易與您的專案程式碼關聯。
有關 sourcemap、它們為何需要以及 ember-cli 如何處理它們的更多資訊,請參閱高階用法:資產編譯指南。請注意,sourcemap 預設啟用。
ember-data 預裝了;我需要它嗎?
完全不需要。雖然 ember-data 解決了任何處理資料的應用程式都會遇到的最常見問題,但也可以自己開發前端資料客戶端。任何功能齊全的前端資料客戶端的一個常見替代方案是 Fetch API。
使用框架提供的設計模式,一個使用 fetch() 的 Route 看起來像這樣
import Route from "@ember/routing/route";
export default class MyRoute extends Route {
async model() {
let response = await fetch("some/url/to/json/data");
let json = await response.json();
return {
data: json,
};
}
}
有關指定 Route 的模型的更多資訊,請參見此處。
為什麼我不能只使用 JavaScript?
這是 Ember 使用者從有 React 經驗的人那裡聽到的最常見問題。雖然在技術上可以使用 JSX 或任何其他形式的 DOM 建立,但目前還沒有任何像 Ember 模板系統那樣健壯的工具。有意的極簡主義強制了某些決策,並允許更一致的程式碼,同時使模板更具結構性,而不是充滿定製邏輯。
mut 助手的現狀如何?
本教程沒有介紹 mut,它實際上是 Ember 從雙向繫結資料轉向更常見、更容易理解的單向繫結資料流的過渡時期遺留下來的包袱。可以將其視為一個構建時轉換,用 setter 函式包裝其引數。
更具體地說,使用 mut 允許宣告僅限模板的設定函式
<Checkbox
@value={{this.someData}}
@onToggle={{fn (mut this.someData) (not this.someData)}}
/>
然而,如果沒有 mut,則需要一個元件類
import Component from "@glimmer/component";
import { tracked } from "@glimmer/tracking";
import { action } from "@ember/object";
export default class Example extends Component {
@tracked someData = false;
@action
setData(newValue) {
this.someData = newValue;
}
}
然後像這樣在模板中呼叫
<Checkbox @data={{this.someData}} @onChange={{this.setData}} />
由於使用 mut 的簡潔性,可能希望使用它。然而,mut 具有不自然的語義,在其存在期間引起了很多困惑。
有幾個新想法以附加元件的形式組合在一起,它們使用公共 API,包括 ember-set-helper 和 ember-box。這兩個都試圖透過引入更明顯/“更少魔法”的概念來解決 mut 的問題,避免構建時轉換和隱式的 Glimmer VM 行為。
使用 ember-set-helper
<Checkbox @value={{this.someData}} @onToggle={{set this "someData" (not
this.someData)}} />
使用 ember-box
{{#let (box this.someData) as |someData|}}
<Checkbox
@value={{unwrap someData}}
@onToggle={{update someData (not this.someData)}}
/>
{{/let}}
請注意,這些解決方案在社群成員中都不常見,總的來說,人們仍在努力尋找一種符合人體工程學且簡單的 API,用於在僅限模板的上下文中設定資料,而無需後端 JS。
控制器的目的是什麼?
控制器是單例,可以幫助管理活動路由的渲染上下文。表面上,它們的功能與元件的後端 JavaScript 非常相似。控制器(截至 2020 年 1 月)是管理 URL 查詢引數的唯一方式。
理想情況下,控制器的職責應該相當輕量,儘可能委託給元件和服務。
路由的目的是什麼?
當用戶在應用程式中從一個地方導航到另一個地方時,路由表示 URL 的一部分。路由只有幾個職責
- 載入渲染路由(或檢視子樹)所需的最少量資料。
- 控制對路由的訪問,並在需要時進行重定向。
- 處理最少量資料的載入和錯誤狀態。
路由只有 3 個生命週期鉤子,所有這些都是可選的
beforeModel— 控制對路由的訪問。model— 資料載入的地方。afterModel— 驗證訪問。
最後,路由能夠處理配置 model 產生的常見事件
loading— 當model鉤子正在載入時該怎麼做。error— 當model丟擲錯誤時該怎麼做。
loading 和 error 都可以渲染預設模板以及應用程式中其他地方定義的自定義模板,從而統一載入/錯誤狀態。