Ember-Ressourcen und Fehlerbehebung

• Ember.JS Leitfäden

  • Tutorial: Super Rentals

• Ember.JS API-Dokumentation

• Ember.JS Discord-Server — ein Forum/Chat-Server, auf dem Sie die Ember-Community treffen, um Hilfe bitten und anderen helfen können!

Dies ist bei weitem keine umfassende Liste, sondern eine Liste von Dingen, die zum Zeitpunkt des Schreibens aufgetaucht sind (letztes Update, Mai 2020).

Für framework-spezifische Dinge gibt es das ember-inspector-Add-On, das die Inspektion folgender Punkte ermöglicht:

• Routen & Controller
• Komponenten
• Dienste
• Zusagen
• Daten (d.h. von einer entfernten API — standardmäßig von ember-data)
• Informationen zu Veralterungen
• Rendering-Leistung

Für allgemeine JavaScript-Fehlerbehebung schauen Sie sich unsere Leitfäden zur JavaScript-Fehlerbehebung sowie die Interaktion mit den anderen Debugging-Tools des Browsers an. In jedem Standard-Ember-Projekt gibt es zwei Haupt-JavaScript-Dateien, vendor.js und {app-name}.js. Beide Dateien werden mit Quellenkarten generiert. Wenn Sie also die vendor.js oder {app-name}.js öffnen, um nach relevantem Code zu suchen und ein Debugger platziert wird, lädt die Quellenkarte und der Haltepunkt wird im vor-transpilierten Code platziert, um die Korrelation zu Ihrem Projektcode zu erleichtern.

Weitere Informationen zu Quellenkarten, warum sie benötigt werden und was der ember-cli damit macht, finden Sie im Erweiterten Einsatz: Asset-Kompilierung-Leitfaden. Beachten Sie, dass Quellenkarten standardmäßig aktiviert sind.

Überhaupt nicht. Während ember-data die häufigsten Probleme löst, auf die jede App stößt, die mit Daten zu tun hat, ist es möglich, Ihren eigenen Frontend-Datenclient zu erstellen. Eine häufige Alternative zu jedem voll ausgestatteten Frontend-Datenclient ist The Fetch API.

Unter Verwendung der vom Framework bereitgestellten Designmuster würde eine Route mit fetch() etwa so aussehen:

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,
    };
  }
}

Weitere Informationen zum Spezifizieren des Route-Modells finden Sie hier.

Dies ist die häufigste Frage, die Ember-Leute von Personen hören, die vorherige Erfahrungen mit React haben. Während es technisch möglich ist, JSX oder jede andere Form der DOM-Erstellung zu verwenden, gibt es noch nichts so Robustes wie das Templating-System von Ember. Der absichtliche Minimalismus erzwingt bestimmte Entscheidungen und führt zu konsistenterem Code, während die Vorlage eher strukturell bleibt, anstatt mit maßgeschneiderter Logik gefüllt zu sein.

Siehe auch: ReactiveConf 2017: Secrets of the Glimmer VM

mut wurde in diesem Tutorial nicht behandelt und ist wirklich ein Überbleibsel aus einer Übergangszeit, als Ember von zweiwegegebundenen Daten zu dem gängigeren und leichter verständlichen einwegegebundenen Datenfluss wechselte. Es könnte als eine Kompilierungszeit-Transformation angesehen werden, die ihr Argument mit einer Setter-Funktion umhüllt.

Konkret ausgedrückt, erlaubt mut die Deklaration von rein funktionsbasierten Template-Einstellungen:

<Checkbox
  @value={{this.someData}}
  @onToggle={{fn (mut this.someData) (not this.someData)}}
/>

Ohne mut wäre eine Komponentenklasse erforderlich:

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;
  }
}

Die dann im Template wie folgt aufgerufen würde:

<Checkbox @data={{this.someData}} @onChange={{this.setData}} />

Aufgrund der Kürze der Nutzung von mut könnte es verlockend sein, darauf zurückzugreifen. Allerdings hat mut unnatürliche Semantiken und hat über sein Bestehen hinweg viel Verwirrung gestiftet.

Es gibt ein paar neue Ideen in Form von Addons, die die öffentlichen APIs nutzen, ember-set-helper und ember-box. Beide versuchen, die Probleme von mut zu lösen, indem sie offensichtlichere / "weniger magische" Konzepte einführen, um Kompilierungszeit-Transformationen und implizites Verhalten des Glimmer VM zu vermeiden.

Mit ember-set-helper:

<Checkbox @value={{this.someData}} @onToggle={{set this "someData" (not
this.someData)}} />

Mit ember-box:

{{#let (box this.someData) as |someData|}}
  <Checkbox
    @value={{unwrap someData}}
    @onToggle={{update someData (not this.someData)}}
  />
{{/let}}

Beachten Sie, dass keine dieser Lösungen besonders häufig unter Mitgliedern der Community ist und insgesamt immer noch versucht wird, eine ergonomische und einfache API für das Setzen von Daten in einem rein auf Templates basierenden Kontext ohne unterstützendes JS zu finden.

Controller sind Singletons, die möglicherweise den Rendering-Kontext der aktiven Route verwalten helfen. An der Oberfläche funktionieren sie ähnlich wie das unterstützende JavaScript einer Komponente. Controller sind (ab Januar 2020) die einzige Möglichkeit, URL-Query-Parameter zu verwalten.

Idealerweise sollten Controller in ihren Verantwortlichkeiten recht leicht bleiben und, wo möglich, an Komponenten und Dienste delegieren.

Eine Route repräsentiert einen Teil der URL, wenn ein Benutzer von einem Ort zum anderen in der App navigiert. Eine Route hat nur einige wenige Verantwortlichkeiten:

• Laden der minimal erforderlichen Daten, um die Route (oder den View-Subtree) darzustellen.
• Zugang zur Route gewähren und bei Bedarf umleiten.
• Umgang mit Lade- und Fehlerzuständen aus den minimal erforderlichen Daten.

Eine Route hat nur 3 Lebenszyklus-Hooks, von denen alle optional sind:

• beforeModel — Zugang zur Route gewähren.
• model — wo Daten geladen werden.
• afterModel — Zugang überprüfen.

Zuletzt hat eine Route die Möglichkeit, auf allgemeine Ereignisse zu reagieren, die sich aus der Konfiguration des model ergeben:

• loading — was zu tun ist, wenn der model-Hook lädt.
• error — was zu tun ist, wenn ein Fehler im model geworfen wird.

Sowohl loading als auch error können Standardvorlagen als auch benutzerdefinierte Vorlagen rendern, die anderswo in der Anwendung definiert sind, sodass Lade- und Fehlerzustände vereinheitlicht werden.

Weitere Informationen darüber, was eine Route alles kann, finden Sie in der API-Dokumentation.

• Zurück
• Übersicht: Verständnis von clientseitigen JavaScript-Frameworks
• Weiter