Während die meisten meiner letzten Arbeiten hauptsächlich mit Ruby on Rails und einer liberalen Dosis von Javascript (hauptsächlich jQuery) gearbeitet haben, möchte ich eine einzelne Seitenanwendung erstellen und feststellen, dass Ember.js ein Up- und beliebtes Framework für die Annäherung an solche Apps.
Aus verschiedenen Quellen von Dokumentation und Tutorials scheint es, dass Ember.js eine ganz andere Art zu denken benötigt, um Probleme zu lösen als Ruby on Rails oder andere typische serverseitige Frameworks. Es scheint möglich zu sein, dass bestimmte Annahmen über die Art und Weise, wie Dinge funktionieren sollten, die man im Laufe der Zeit unter Verwendung eines Frameworks wie Ruby on Rails entwickelt, dem "Ember Way" sogar im Wege stehen könnten
Welche vorgefassten Meinungen sollte ein Ruby on Rails-Entwickler beseitigen müssen, wenn er versucht, Ember zu lernen? Und was sind die innovativsten und wichtigsten Ember-Konzepte, die ein Ruby on Rails-Entwickler ausprobieren sollte?
Vielen Dank im Voraus!
Ich werde mein Bestes tun, um diese Frage im Sinne von StackOverflow zu beantworten, indem ich einige wichtige technische Unterschiede zwischen Ember und Rails aufzähle. Ich überlasse die eher philosophische Seite für jemand anderen bei programmers.stackexchange.com .
Sie können alle unten aufgeführten Codebeispiele in einem funktionierenden jsFiddle finden, wenn Sie dadurch besser sehen können, wie alles zusammenpasst.
Ein wichtiger Unterschied zwischen Ember und Rails ist die Beziehung zwischen Sammelrouten (die eine Liste von Objekten verwalten) und Artikelrouten (die ein einzelnes Objekt verwalten). In Rails werden beide von einem einzelnen Ressourcen-Controller verarbeitet. In Ember werden diese im Allgemeinen durch zwei getrennte Routen gehandhabt, weil sie zwei verschiedene Datenstrukturen manipulieren:
%Vor%In Rails ist Ihr Code in drei Hauptklassen unterteilt:
In Ember unterscheidet sich die Aufteilung der Verantwortlichkeiten erheblich.
Modelle. Ember-Modelle funktionieren ähnlich wie Rails-Modelle.
%Vor% Routen. Routen stellen für den Benutzer sichtbare Orte in Ihrer App dar und entsprechen URLs wie /post/7 oder /about . Wie Sie in den obigen Codebeispielen sehen können, machen Routen in Ember viel mehr. Am wichtigsten ist, dass sie die einer bestimmten URL entsprechenden Modelle nachschlagen. Sie sind auch verantwortlich für den Anschluss entsprechender Controller und Ansichten, wie Sie gleich sehen werden.
Controller. Controller sind nichts mit Rails! Die zwei wichtigsten Dinge, die man über Ember-Controller verstehen sollte, sind: (1) Sie sind im Grunde intelligente Proxies um Modellobjekte, und (2) sie sind normalerweise Singletons. Sie haben also nur ein PostController , das mit dem Post, den Sie gerade ansehen, verbunden ist.
Im Allgemeinen verwenden Sie Ember-Controller, um Übergangszustände zu verwalten, die nicht in die URL oder in die Datenbank gehören. Hier ist ein Beispiel:
%Vor%Da Ember-Controller Proxys um Modelle herum sind, neigen sie auch dazu, Logik zu sammeln, die fast in das Modell gehört, sich aber zu sehr an einen bestimmten Bildschirm in Ihrer App gebunden fühlt.
Ansichten und Vorlagen. Ember-Ansichten und Vorlagen arbeiten zusammen. Es empfiehlt sich, sie als GUI-Widget zu betrachten.
%Vor%Unsere Postvorlage mischt frei Felder, die durch das Modell und die vom Controller definierten Felder definiert sind:
%Vor%Beachten Sie, dass die Ansicht, wenn sich die Felder in unserem Modell oder Controller ändern, automatisch nur die Teile des HTML-Codes neu darstellt, die aktualisiert werden müssen!
Da Ember.js im Browser ausgeführt wird, sind viele Vorgänge asynchron. Ein Großteil von Embers grundlegendem Design basiert darauf, asynchrone Aktualisierungen angenehm und einfach zu machen. Eine wichtige Konsequenz dieser Situation ist, dass Objekte asynchron geladen werden. Wenn Sie find aufrufen, erhalten Sie ein nicht geladenes Objekt zurück:
Wenn der Server Ihnen die Daten sendet, sehen Sie:
%Vor% Um das zu vereinfachen, verlässt sich Ember stark auf berechnete Eigenschaften , observer und Bindungen . In jedem dieser Fälle besteht die Schlüsselidee darin, dass Änderungen an Daten automatisch durch das System übertragen werden. Zum Beispiel können wir eine berechnete Eigenschaft verwenden, um sicherzustellen, dass isLowRated jedes Mal aktualisiert wird, wenn sich der rating eines Kommentars ändert:
Beachten Sie, dass die Ember's Lenker-Vorlagen tief in dieses System integriert sind. Wenn Sie {{title}} in eine Vorlage schreiben, erstellen Sie eine Bindung, die das DOM automatisch aktualisiert, wenn title sich ändert. Bei Bearbeitungsfeldern funktioniert diese Bindung in beide Richtungen! Änderungen an einem angezeigten Wert werden direkt zum Modell zurückgeschoben (obwohl Transaktionen zum Zurückrollen verwendet werden können).
Beachten Sie auch, dass viele der dynamischen Aktualisierungen - insbesondere Bindungen - am Ende der aktuellen "Ausführungsschleife" asynchron ausgeführt werden. Aus diesem Grund werden in Testsuiten häufig Aufrufe von Ember.run angezeigt:
In der Praxis fühlt sich Ember wesentlich asynchroner an als Rails, aber weniger asynchron als ein ausgeglichenes System wie Node.js. Dies liegt daran, dass die meisten asynchronen Aktualisierungen automatisch durch Bindungen verwaltet werden.
Dies ist der eine Ort, an dem ich von rein technischen Details abweichen und einige praktische Ratschläge erwähnen werde.Ember Data liefert DS.Model , wie oben zu sehen. Es ist nicht die einzige Modellschicht für Ember.js-check-out Glut-Rest , ber-resource und ähnliche Bibliotheken für Alternativen. Zu diesem Zeitpunkt gibt es keine offizielle Veröffentlichung von Ember Data, aber es kann in Produktions-Apps sehr vorsichtig verwendet werden, wenn Sie auf der Höhe der Zeit leben wollen. Einige Tipps:
hasMany -Beziehung in Rails serialisiert wird. Siehe active_model_serializers , wenn Sie Rails verwenden. Es ist möglich, mit Ember Data sehr gute Ergebnisse zu erzielen. Aber es ist wesentlich weniger ausgereift als ActiveModel und muss als solches behandelt werden.
Tags und Links javascript ruby-on-rails model-view-controller ember.js