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, aber es ist eine Liste von Dingen, die zum Zeitpunkt des Schreibens (letztes Update, Mai 2020) aufkamen.

Für framework-spezifische Dinge gibt es das ember-inspector Add-on, das die Inspektion der folgenden Elemente ermöglicht:

• Routen & Controller
• Komponenten
• Dienste
• Versprechen
• Daten (d.h. von einer Remote-API — standardmäßig von ember-data)
• Informationen zur Abschaffung
• Renderleistung

Für allgemeines JavaScript-Debugging werfen Sie einen Blick auf unsere Leitfäden zum JavaScript-Debugging sowie auf die Interaktion mit den anderen Debugging-Tools des Browsers. In jedem Standard-Ember-Projekt gibt es zwei Haupt-JavaScript-Dateien, vendor.js und {app-name}.js. Beide Dateien werden mit Sourcemaps generiert, sodass beim Öffnen der vendor.js oder {app-name}.js, um relevanten Code zu suchen, beim Platzieren eines Debuggers die Sourcemap geladen wird und der Haltepunkt im vor-transpilierten Code platziert wird, um eine einfachere Korrelation zu Ihrem Projektcode zu ermöglichen.

Weitere Informationen zu Sourcemaps, warum sie benötigt werden und was der ember-cli mit ihnen macht, finden Sie im Fortgeschrittene Nutzung: Asset-Kompilierung Leitfaden. Beachten Sie, dass Sourcemaps standardmäßig aktiviert sind.

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

Die vom Framework bereitgestellten Designmuster verwendend, würde eine Route mit fetch() etwa wie folgt 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-Anwender von Personen hören, die bereits Erfahrung mit React haben. Obwohl es technisch möglich ist, JSX oder jede andere Form der DOM-Erstellung zu verwenden, gibt es bisher nichts so Robustes wie das Templating-System von Ember. Der absichtliche Minimalismus erzwingt bestimmte Entscheidungen und ermöglicht konsistenteren Code, während das Template mehr strukturell bleibt, statt voll mit maßgeschneiderter Logik 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 bidirektionaler Datenbindung zu dem gebräuchlicheren und leichter nachvollziehbaren unidirektionalen Datenfluss überging. Es könnte als eine Build-Zeit-Transformation betrachtet werden, die ihr Argument mit einer Setter-Funktion umwickelt.

Konkreter ausgedrückt, ermöglicht die Verwendung von mut die Deklaration von Vorlagen-spezifischen Einstellungsfunktionen:

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

Ohne mut wäre jedoch 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 so aufgerufen würde:

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

Aufgrund der Kürze von mut könnte es wünschenswert sein, darauf zurückzugreifen. mut hat jedoch unnatürliche Semantiken und hat während seiner Existenz viel Verwirrung gestiftet.

Es wurden einige neue Ideen in Form von Addons zusammengestellt, 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, die Build-Zeit-Transformationen und implizites Glimmer-VM-Verhalten 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 weit verbreitet unter den Mitgliedern der Community ist, und insgesamt versuchen die Leute immer noch, eine ergonomische und einfache API zu finden, um Daten in einem nur mit Vorlagen arbeitenden Kontext zu setzen, ohne unterstützendes JS.

Controller sind Singletons, die helfen können, den Rendering-Kontext der aktiven Route zu verwalten. Oberflächlich betrachtet funktionieren sie ähnlich wie das unterstützende JavaScript einer Komponente. Controller sind (Stand: Januar 2020) die einzige Möglichkeit, URL-Query-Parameter zu verwalten.

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

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

• Laden der minimal erforderlichen Daten, um die Route (oder den Ansichts-Unterbaum) zu rendern.
• Zugriff auf die Route steuern und ggf. umleiten.
• Lade- und Fehlerzustände der minimal erforderlichen Daten behandeln.

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

• beforeModel — Zugriff auf die Route gewähren.
• model — wo Daten geladen werden.
• afterModel — Zugriff verifizieren.

Zuletzt hat eine Route die Fähigkeit, häufige Ereignisse zu behandeln, 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 aus model geworfen wird.

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

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

• Zurück
• Übersicht: JavaScript-Frameworks und -Bibliotheken