Ember-Ressourcen und Fehlersuche

Weitere Ressourcen

• 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!

Allgemeine Fehlersuche, Fallstricke und Missverständnisse

Dies ist keineswegs eine umfassende Liste, aber sie enthält Dinge, die zur Zeit des Schreibens aufgekommen sind (letztes Update, Mai 2020).

Wie debugge ich, was im Framework vor sich geht?

Für framework-spezifische Dinge gibt es das ember-inspector Add-on, das die Inspektion von Folgendem erlaubt:

• Routen & Controller
• Komponenten
• Dienste
• Promises
• Daten (z.B. aus einer entfernten API — standardmäßig von ember-data)
• Informationen zu Veraltungen
• Render-Performance

Für allgemeine JavaScript-Fehlersuche, schauen Sie sich unsere Leitfäden zur JavaScript-Fehlersuche sowie die Interaktion mit anderen Debugging-Tools des Browsers an. In jedem Standard-Ember-Projekt gibt es zwei Haupt-JavaScript-Dateien, vendor.js und {app-name}.js. Beide werden mit Sourcemaps generiert, sodass beim Öffnen der vendor.js oder {app-name}.js, um nach relevantem Code zu suchen, eine Debugger-Platzierung die Sourcemap lädt und der Haltepunkt im prä-transpilierten Code für eine einfachere Zuordnung zu Ihrem Projektcode platziert wird.

Für mehr Informationen über Sourcemaps, warum sie benötigt werden und was der ember-cli damit macht, siehe den Advanced Use: Asset Compilation Leitfaden. Beachten Sie, dass Sourcemaps standardmäßig aktiviert sind.

ember-data ist vorinstalliert; brauche ich es?

Überhaupt nicht. Während ember-data die häufigsten Probleme löst, die jede App beim Umgang mit Daten haben wird, ist es möglich, Ihren eigenen Front-End-Datenclient zu entwickeln. Eine gängige Alternative zu einem voll funktionsfähigen Front-End-Datenclient ist The Fetch API.

Mit den vom Framework bereitgestellten Designmustern würde eine Route, die fetch() verwendet, 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 festlegen des Route-Modells finden Sie hier.

Warum kann ich nicht einfach JavaScript verwenden?

Dies ist die häufigste Frage, die Ember-Leute von Personen hören, die bereits Erfahrung mit React haben. Während es technisch möglich ist, JSX oder eine andere Form der DOM-Erstellung zu verwenden, hat sich noch nichts als so robust erwiesen wie das Templating-System von Ember. Der bewusste Minimalismus zwingt zu bestimmten Entscheidungen und ermöglicht konsistenteren Code, während das Template mehr strukturiert bleibt, anstatt sie mit individueller Logik zu füllen.

Siehe auch: ReactiveConf 2017: Secrets of the Glimmer VM

Was ist der Zustand des mut-Hilfsmittels?

mut wurde in diesem Tutorial nicht behandelt und ist wirklich Ballast aus einer Übergangszeit, als Ember von zweiwegegebundenen Daten zu den gebräuchlicheren und leichter verständlichen einwegegebundenen Datenflüssen wechselte. Es könnte als eine Buildzeit-Transformation angesehen werden, die ihr Argument mit einer Setter-Funktion umschließt.

Konkret ermöglicht die Verwendung von mut, dass nur im Template Funktionen zur Einstellung deklariert werden:

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

Ohne mut wäre hingegen 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 Prägnanz der Verwendung von mut mag es wünschenswert sein, darauf zurückzugreifen. Allerdings hat mut unnatürliche Semantiken und hat während seiner Existenz viel Verwirrung verursacht.

Es wurden einige neue Ideen in Form von Addons zusammengefasst, die die öffentlichen APIs verwenden, ember-set-helper und ember-box. Beide versuchen, die Probleme von mut zu lösen, indem sie offensichtlichere / "weniger magische" Konzepte einführen, die auf Buildzeit-Transformationen und implizites Glimmer VM-Verhalten verzichten.

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 den Mitgliedern der Gemeinschaft ist, und insgesamt versuchen die Menschen immer noch, eine ergonomische und einfache API zu finden, um Daten in einem nur auf Vorlagen basierenden Kontext ohne Unterstützung durch JS zu setzen.

Was ist der Zweck von Controllern?

Controller sind Singletons, die helfen können, den Rendering-Kontext der aktiven Route zu verwalten. An der Oberfläche funktionieren sie ähnlich wie das unterstützende JavaScript einer Komponente. Controller sind (Stand Januar 2020) der einzige Weg, um URL Query Params zu verwalten.

Idealerweise sollten Controller eher leicht in ihren Aufgaben sein und wo möglich an Komponenten und Dienste delegieren.

Was ist der Zweck von Routen?

Eine Route repräsentiert einen Teil der URL, wenn ein Benutzer innerhalb der App von einem Ort zum anderen navigiert. Eine Route hat nur ein paar Verantwortungen:

• Laden der minimal erforderlichen Daten zum Rendern der Route (oder Unteransicht).
• Gewährung des Zugangs zur Route und Umleitung bei Bedarf.
• Umgang mit Lade- und Fehlerzuständen der minimal erforderlichen Daten.

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

• beforeModel — gewährt Zugang zur Route.
• model — wo Daten geladen werden.
• afterModel — Überprüfung des Zugangs.

Zuletzt hat eine Route die Fähigkeit, auf allgemeine Ereignisse zu reagieren, die aus der Konfiguration des model resultieren:

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

Sowohl loading als auch error können Standard-Templates sowie anderswo in der Anwendung definierte benutzerdefinierte Templates rendern, was Lade-/Fehlerzustände vereinheitlicht.

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

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