Backbone: Benutzerdefinierte Backbone-Builds

Es wäre toll.

Wenn Sie daran interessiert sind, wie ich die Backbone.js-Codebasis modularisiert habe, sehen Sie sich den Ordner customBuild in meinem Backbone-Fork an. Denken Sie daran, dass alle Backbone-Komponententests weiterhin erfolgreich bestehen.
https://github.com/gfranko/backbone/tree/modularBuilds

Hier ist auch ein Beispiel dafür, wie eine benutzerdefinierte Build-Benutzeroberfläche funktionieren würde:
http://gregfranko.com/backbone/customBuild/

Schließlich ist hier ein Blog-Beitrag, den ich geschrieben habe, um zu diskutieren, ob möglicherweise nur einige Teile von Backbone verwendet werden:
http://gregfranko.com/blog/backbone-dot-js-convincing-the-boss-guide/

Ich schätze die Idee sehr, besonders den Teil, in dem die Ruby-Abhängigkeiten verschwunden sind und das Grunzen ins Spiel kommt.

Außerdem gibt es Situationen, in denen ich Backbone.Router nicht benötige (Weil ich etw. nicht zum Routen habe, aber trotzdem gerne Backbone zum Organisieren meines JavaScripts nutze).

Außerdem passt das sehr gut zu LoDash-Custom-Builds (äh, hoffentlich ist niemand sauer).

@asciidisco Ich habe noch nicht die Arbeit gemacht, benutzerdefinierte Builds in Grunt zu integrieren. Hast du eine Idee, wie du das angehen würdest?

@gfranko Würde gerne eine jQuery-ähnliche Implementierung sehen (seit 1.8 gibt es auch benutzerdefinierte Builds),
vielleicht forke ich dein Projekt auf & probiere es dieses Wochenende aus, aber ich bin mir nicht ganz sicher, ob ich genug Zeit habe :(

@asciidisco Mach dir keine Sorgen. Ich werde mir dieses Wochenende die jQuery-Grunt-Datei ansehen, um zu sehen, wie sie es machen.

:+1: zur Modularisierung der Codebasis

Obwohl mehrere Dateien oft nützlich sind, glaube ich nicht, dass Backbone von einer Aufteilung der Quelle profitieren würde. Die Bibliothek ist ziemlich klein, sodass benutzerdefinierte Builds bestenfalls nur wenige Kilobyte sparen, während die zusätzliche Komplexität erheblich wäre.

Für was es wert ist, wurde dies mindestens einmal zuvor in #65 diskutiert.

Wie sieht es mit Anwendungsfällen aus, beispielsweise wenn ein Benutzer jQuery Mobile mit Backbone.js verwendet und keine Backbone-Routen einschließen möchte?

Ich stimme zu, dass die Standard-Backbone-Quelle als eine Datei verbleiben sollte, aber ich schlug vor, dass die Aufteilung der Quelle in mehrere Dateien (ich weiß, dass dies mehr Arbeit erfordert) auch hinzugefügt werden könnte, falls ein Benutzer eine bestimmte Funktion nicht wünscht.

Außerdem habe ich in meinem Blog-Beitrag vorgeschlagen, dass es die Verwendung von Backbone in einer Unternehmensumgebung noch einfacher machen würde, wenn Benutzern nicht alle Funktionen von Backbone zur Verfügung stehen.

Und nur neugierig, was wäre die zusätzliche Komplexität?

Wie sieht es mit Anwendungsfällen aus, beispielsweise wenn ein Benutzer jQuery Mobile mit Backbone.js verwendet und keine Backbone-Routen einschließen möchte?

Löschen Sie es einfach aus der Quelle. Es ist ziemlich klar beschriftet und recht einfach zu machen.

Und nur neugierig, was wäre die zusätzliche Komplexität?

Ich beziehe mich auf die Komplexität für neue und bestehende Mitwirkende. Das Schreiben von Code für ein neues Projekt ist immer entmutigend, und wir möchten es so weit wie möglich fördern. Derzeit erfordert Backbone nur einen Browser, der lokale Dateien bereitstellt, und einen Texteditor. Ein Build-System/Tool zu benötigen ist ein großer Schritt nach oben.

Ich bin jedoch nicht gegen benutzerdefinierte Builds im Allgemeinen und mag das Tool, das Sie in Ihrem Blogbeitrag vorstellen, eher. :)

Sie haben Recht, jedes Backbone-Klassenobjekt ist eindeutig beschriftet (weshalb es für mich so einfach war, die Codebasis aufzuteilen). Davon abgesehen glaube ich nicht, dass die meisten Entwickler die Quelle einer Bibliothek berühren möchten, die sie verwenden.

Sehen Sie sich als Beispiel Require.js und nicht-AMD-kompatible Skripte an. Es ist einfach, eine lib in eine define-Methode einzuschließen, aber wer will das schon?

Aber ja, ich höre, was Sie sagen, um nicht zu viele Abhängigkeiten / Komplexitäten einzuführen. Ich schätze, ich werde dies einfach als separates Projekt behalten und den Code mit der Backbone-Quelle auf dem neuesten Stand halten.

Yep -- ich denke, es ist ein wirklich nettes Projekt ... aber Backbone profitiert davon, ein einfaches, einzelnes Skript zu sein. Wenn Sie Backbone installiert haben, haben Sie es, Punkt, und Sie können sich darauf verlassen, dass alles, was es bietet, verfügbar ist.

braddunbar: Einfach aus der Quelle löschen. Es ist ziemlich klar beschriftet und recht einfach zu machen.

Gah, es ist eine Falle! Ein offizielles Build-System zu haben, um Qualität, Kompatibilität und Funktionalität zu gewährleisten, ist besser.

jashkenas: Ja -- ich denke, es ist ein wirklich nettes Projekt ... aber Backbone profitiert davon, dass es ein einfaches, einzelnes Skript ist.

Ja, ich grabe auch einzelne Dateien, weshalb Lo-Dash eine einzelne Datei ist, aber immer noch benutzerdefinierte Builds unterstützt (obwohl jQuery es mit einzelnen Dateien in seinem Repository funktioniert).

Benutzerdefinierte Builds sind großartig und geben Entwicklern mehr Kontrolle. Da Lo-Dash und jQuery benutzerdefinierte Builds unterstützen, fehlt nur noch Backbone ;D

Hey,
Wenn einer von euch interessiert ist, habe ich ein Grunt-Plugin erstellt, um benutzerdefinierte Backbone-Builds zu generieren
die "normalen" Backbone-Quelldateien: https://github.com/asciidisco/grunt-backbonebuilder

Noch nicht wirklich getestet (obwohl ich eine Backbone-Version betreibe, bei der der gesamte Router- und Verlaufskram weggelassen wurde), was funktioniert
Gut. Rückmeldung erwünscht.

@asciidisco Danke, du

Es wäre schön, wenn wir zu browserify oder webpack wechseln würden, damit wir problemlos das Beste aus beiden Welten (mehrere Dateien und eine einzelne Datei) haben.

Es wäre schön, Events als separates Modul zu haben. Sehr nützlich, wenn benutzerdefinierte Module mit optionalen Model s- und Collection s-Abhängigkeiten erstellt werden.

Ich verwende das Backbone-Modell und die Sammlung in meinen Angular- und AngularJS-Projekten. Ich brauche nur das Modell und die Kollektion, weil das Konzept das Konzept genial ist. Ich verwende ist als Datenzugriffsschicht. Angular stellt die UI-Schicht bereit.

Ich habe kürzlich einen Artikel darüber geschrieben, wie Sie von der Verwendung von BackboneJS in einer Angular-App profitieren können: https://docs.google.com/document/d/1ptYmQzjq8EWLKyqFENqyXwzz67VNWzh_-clhy4W5R40

Es wäre wirklich schön, BackboneJS in mehrere Komponenten aufzuteilen, damit Sie nur die Dinge aufnehmen können, die Sie benötigen.

@jashkenas Wie wäre es, die src-Dateien in mehrere Dateien aufzuteilen und sie von einer Build-Aufgabe zu einer Datei zusammenzufassen, damit Sie beides haben:

• eine einfache einzelne Datei
• und Quelldateien aufteilen
  ?