Angular.js: ANFRAGE UM FEEDBACK: `angular.component()` - Name des Standarddirektiven-Controllers

c) Programmierer sind versucht, isolate:false zu verwenden und direkt auf Vorfahren-Controller zuzugreifen.

@drpicox - Ich bin versucht zu sagen, dass wir isolate: false für Komponenten verbieten, die mit diesem Helfer erstellt wurden.

Ich stimme zu, nachdem ich Folgendes überlegt habe:

• isolate: true wenn Beschränkung 'E' ist: für mich sind sie wirklich Komponenten, in denen $ctrl Notation volle Bedeutung hat
• isolate: false wenn einschränken 'A' ist: für mich sind sie _decorators_, eine Art Enhancer der bestehenden Komponenten, in diesem Fall kollidiert $ctrl, also ist die aktuelle Nomenklatur in Ordnung

Aber ich bin der Meinung, dass der zweite Fall besser mit Direktiven zu tun hat, _Dekoratoren_ sind nicht häufig, normalerweise auf niedrigem Niveau und nicht für Junioren geeignet.

Es ist also wahrscheinlich eine gute Idee, isolate: false zu verbieten.

In einer anderen Denkweise über _Decorators_ sollte eine Funktion zum Abrufen des Controllers der 'E'-Komponente der aktuellen Entität eine gute Idee sein, insbesondere um generische _Decorators_ zu schreiben, um mit jeder aktuellen Komponente umzugehen (erfordert Kräfte, im Voraus zu wissen, welcher Controller ist und Sie können keine Art von Schnittstelle für das verwenden, wonach Sie suchen).

Ich mag $cmp , finde aber $comp noch besser, weil es übersichtlicher ist.

Ich mag $cmp , finde aber $comp noch besser, weil es übersichtlicher ist.

Ich mag $comp . Immer wenn ich $cmp sehe, denke ich "vergleichen".

anderer Vorschlag: Warum nicht den Namen der Komponente als Controller-Instanznamen verwenden?
Beispiel: Benutzerprofil -> Bereich.Benutzerprofil

@tabanliviu So wird es derzeit bei master gemacht, aber @petebacondarwin hat in genau dieser Ausgabe, im ersten Post, erwähnt, warum ein gemeinsamer Name besser ist.

@mgol :+1: Ich glaube, ich habe das beschönigt, als ich das Ticket gelesen habe. Sollte diese Änderung eher als ngUpgrade-Problem betrachtet werden? Ich denke im Zusammenhang mit Angular 1.x ist die aktuelle Implementierung eine gute Lösung. Vielleicht als Einstellungsfunktion verfügbar machen, die den Komponentennamen übernimmt und den Controller-Namen ausgibt? Auf diese Weise dient es dem aktuellen Muster und einem zukünftigen Migrationspfad.

Bikeshed-Zeit.

+1 für $ctrl.

Ctrl hat viele bereits vorhandene Kultur in der Angular 1-Dokumentation und Beispiele als Suffix „Controller“. Versuchen Sie, "angular ctrl" für ein gutes Maß zu googeln.

Die aktuelle Wahl, es vom Komponentennamen abzuleiten, ist ziemlich unangenehm, da sie in realen Anwendungen in der Tat dazu neigen, ziemlich lang zu werden.

:+1: für $ctrl fühlt sich $vm standardmäßig eher wie eine Aussage darüber an, wie Controller verwendet werden sollten.

+1 für $ctrl .

Wir haben im ng-forward-Team ziemlich heftig darüber diskutiert und entschieden, dass ctrl ein weniger belasteter Begriff ist als vm .

Ich stimme für $ctrl und würde mich sehr freuen, wenn dies die Leute dazu ermutigt, ihre Controller nicht mehr vm zu nennen :P

Ach, das möchte ich auch noch ergänzen

dies kann mit Eingabesteuerelementen verwechselt werden

Nö. Nicht wirklich.

$ctrl

Ich denke, das wäre für jeden am verständlichsten und intuitivsten.

+1 $ctrl

Andere Vorschläge:

1. $as - wie Controller als
2. $at - wie @ - während es im Kaffee-Skript auf "diesen" Kontext verweist
3. $class - obwohl 5 Zeichen, kommt es der Notation der ng2-Komponentenklasse nahe.
4. $prox - da die Ctrl-Instanz konzeptionell ein Proxy für eine Dienstschicht ist
5. $ctx - Abkürzung für Kontext
   Danke.

Ich stimme für $this , weil in ng2 this des Controllers der Kontext der Vorlage ist (und meiner Meinung nach ist component sehr gut als Übergangswerkzeug zwischen ng1 und ng2).

+1 für $ctrl

Ich bevorzuge auch die Eigenschaft $ctrl , da sie den Komponenten-Controller darstellt.

+1 für $ctrl

+1 für $dies

Ich würde sogar mit this gehen und $ fallen lassen, wenn es nicht zu viel Hack wäre, es zu tun. Es ist auch die einzige Option, die nicht kurz für etwas anderes steht, und ich hasse Abkürzungen. :)

Ich würde $ctrl oder $cc wählen (kurz für Component Controller)

+1 für $ctrl

Wir könnten es einfach $troll nennen, es hat ein bisschen $this und die Hälfte von $controller . Nein, nur ein Scherz, mir geht es gut mit $ctrl . :+1:

$Strg + 1

$VM

Vorteile

• weniger neue Konzepte
• kurz
• stellt nicht dar, was das Objekt wirklich ist (aber wechselnde Entwickler werden es verstehen ... und das ist der Punkt)

Nachteile

• stellt nicht dar, was das Objekt wirklich ist (aber wechselnde Entwickler werden es verstehen ... und das ist der Punkt)

$ctx - Abkürzung für Kontext.

Allgemeiner als $ctrl , weniger anonym als $vm , keine Verwirrung wie $comp oder $this .

Ich habe mir die Template-Engines (Jade, Handlebars, Moustache.js, Dust.js, Nunjucks, EJS usw.) angesehen und es scheinen die Namen context , locals oder data zu sein

Auch $ctx hat für den Kontext nicht die gleiche kognitive Überlastung wie $ctrl (oder $this ) und tatsächlich sagten Sie in Angular 2, where the context is the controller .

@albertosantini - Ein Problem mit $ctx ist, dass der aktuelle Kontext der aktuelle Bereich ist, auf den auch direkt von this zugegriffen werden kann.

$vc - steht für View Controller.
Ich habe eine Referenz in Apples Dokumenten gefunden

tldr;

"... Die UIViewController-Klasse definiert die Methoden und Eigenschaften zum Verwalten Ihrer Ansichten, zum Behandeln von Ereignissen ... "

Ich stimme stark für $this :

<textarea ng-change="$this.handleChange">

_Vorteile:_

• Größter Vorteil : Sie müssen in Ihrem Controller keine ctrl = this machen, damit beide Entitäten gleich aussehen.
• Alles andere als $this fühlt sich an, als würde Angular sogar _"mehr proprietäre Sprache"_ einführen, was eine der beliebtesten Beschwerden über Angular ist. Ihr Controller wird so verschmutzt:

  controller: function() {
    var ctrl = this;

    ctrl.items = [];
    ctrl.text = '';
    ctrl.handleSubmit = function () {
        ctrl.items.push({text: ctrl.text});
        ctrl.text = '';
    };
  }

anstelle des saubereren, eleganten und Framework-agnostischen

  controller: function() {
    this.items = [];
    this.text = '';
    this.handleSubmit = function () {
       this.items.push({text: this.text});
       this.text = '';
    };

• Letzteres ist eine reine JavaScript-Funktion, die mit oder ohne Angular überall wiederverwendet werden kann. Ersteres würde woanders aus dem Zusammenhang gerissen wirken.
• Beachten Sie, dass sogar der Syntax-Highlighter im letzten Snippet Ihr Freund ist und wie er Sie im ersteren bekämpft. Code-Lesbarkeit ist ein wichtiges Thema.
• Diese Syntax ähnelt React, wie sie auf ihrer Zielseite angezeigt wird:

<textarea onChange={this.handleChange}>

• In React werden sowohl der DOM-Kontext als auch die Controller-Instanz als genau dieselben Entitäten behandelt, und React nutzt dies sogar aus und behauptet, ihr Ansatz sei einfacher.
• Angular ist sicherlich nicht React, aber viele Leute verwenden oder sehen sich beide an, sodass sich mehr Ähnlichkeit für sie freundlicher und weniger verwirrend anfühlen würde.

@dmitriz Ein Problem mit $this in AngularJS ist, dass der Kontext (dh this ) in der Vorlage nicht wirklich der Controller ist. Es scheint, dass sie in React (und Angular 2) wirklich dasselbe sind, und daher ist es sinnvoll, this (oder $this ) zu verwenden. In Angular 1 sind sie nicht gleich und daher könnte $this tatsächlich noch mehr Verwirrung stiften.

In Bezug auf die JavaScript-Seite ist es im ES5-Code sehr üblich, this wegen der Bindungsprobleme von this beim Aufrufen freier Methoden als Alias ​​für this zu verwenden. Daher haben Controller immer noch oft so etwas wie var that = this , in diesem Fall kann man auch var ctrl = this verwenden.

Davon abgesehen ist es nicht erforderlich, dies in Ihren Controllern zu tun, wenn Sie dies nicht möchten. Es ist meiner Meinung nach vollkommen vernünftig, this intern in einem Objekt zu verwenden, aber dann auf ein Objekt mit einem anderen Namen zu verweisen, wenn es von außen verwendet wird.

@dmitriz , Sie müssen nicht denselben Alias ​​im Controller und in der Ansicht haben (das tue ich nie). Außerdem verwende ich immer var self = this im Controller, um zu vermeiden, dass ich .bind(this) für Rückrufe usw.
Das sollte also kein Problem sein, imo.

Zu anderen Optionen:

• $ctx : Das gefällt mir nicht, weil (wie @petebacondarwin erwähnte) der Controller nicht der Kontext der Ausdrücke ist.
• $this : Das gefällt mir nicht, weil (in Winkelausdrücken) this ein spezieller Alias ​​für den aktuellen Geltungsbereich ist, also this --> scope und $this --> controller hat wäre noch verwirrender. (Ich hätte es mir anders gewünscht.)
• $vm : Ich mag das nicht (aus bereits erwähnten Gründen), aber ich könnte damit gehen, wenn nichts Besseres unseren Einschränkungen entspricht.
• $cmp : Nicht sehr zufriedenstellend (weil nicht 100% genau), aber aussagekräftig genug. Könnte damit gehen, wenn nichts Besseres unseren Einschränkungen entspricht.
• $comp : Ich bevorzuge $cmp , weil es kürzer ist (und ich finde es nicht "verwechselbarer" mit compare als $comp ).
• $ctrl : Das gefällt mir ziemlich gut. Es ist ziemlich kurz, deklarativ und so genau, wie es nur sein kann. Ich habe meinen Controllern immer ctrl angehängt und ich habe nie eine Verwechslung mit ConTRoL erlebt (aber sachkundigere Leute bestehen darauf, dass es Verwirrung gegeben hat :)). Wenn wir entscheiden, dass Verwirrung kein Problem ist, würde ich definitiv mit diesem gehen, aber ich bin mit etwas anderem einverstanden.
• $troll : Ich muss noch etwas darüber nachdenken. Potenzial hat es auf jeden Fall :stuck_out_tongue:
• Andere Optionen ( $as , $at , $cc , $prox , $vc ): Ich denke, sie führen neue Konzepte ein und es werden noch mehr sein verwirrend als hilfreich.

Ich stimme für $ctrl , weil es der Direktiven-Controller _ist_. Einfach.

Gegen die anderen:

• $vm -- Wie bereits erwähnt, ist dies keine erforderliche Verwendungsabsicht => entweder Verwirrung beim Lesen von Mustern/Codes oder weniger Auswahl für den Entwickler (erzwungen, vm zu implementieren)
• $cmp -- Nun, es ist nicht die Komponente selbst, sondern (nur) der Controller? Also eigentlich irreführend?
• $this -- Auch schon erwähnt, es ist verwirrend. Was macht die Controller-Instanz im Bereich "dies"? Semantisch sehe ich nicht, dass das ... na ja ... verständlich sein könnte?
• $ctx -- Eigentlich dasselbe wie $this .

Auch wie Pascal schon sagte: Ich sehe keine Verwechslung mit Bedienelementen. Sofern Angular2 nicht alle DOM-/Eingabeelemente auf diese Weise einfügt (dh $ctrl, $val, $cmbx usw.), sehe ich darin kein Problem.

+1 $ctrl

In derselben Zeile wie vorherige Kommentare:

• $vm , $as , $at , $cc , $prox , $vc , $ctx ,. ..: stellt Programmierern neue unnötige Konzepte vor
• $this : Da this bereits existiert, kann es für Programmierer verwirrend sein
• $cmp oder $comp : (besser zuerst) Es sollte nett sein, weil es Programmierer auf das Komponentenmodell konzentriert, aber sie sind möglicherweise nicht einfach
• $ctrl : ist genau das, was im Geltungsbereich veröffentlicht wird, der Controller, also scheint es wirklich einfach zu verstehen und zu verwenden

Ich verstehe, danke für die Klarstellung, ich kannte this = $scope nicht, aber ja, das schließt es aus.

Dann klingt $ctrl nach der nächstbesten Wahl, abgesehen von $troll also :)

+1 für $ctrl : am intuitivsten und allgemeinsten

@petebacondarwin Danke für die Details.

Also +1 für $ctrl .

Ich bevorzuge den deklarativen $ctrl als Standardnamen.

Warum nicht gut?

@petebacondarwin @PascalPrecht

Warum ist VM keine gute Darstellung?

(Wenn Sie es bereits zu einem anderen Thema besprochen haben, verlinken Sie es einfach, wenn Sie können)

Denn AFAIK, Controller in Angular sind eher View Models als klassische Controller von MVC. aber vielleicht übersehe ich etwas.

+1 für $vm

Ich stimme den Punkten von @QuinntyneBrown zu -

es ist kürzer.

aber wichtiger -

Der Styleguide von @johnpapa ist sehr beliebt, und viele Leute, die ich kenne, beziehen sich darauf als Teil ihres Schulungsprogramms für „neue Entwickler“.

Wenn wir dies hier ändern, sollten wir die Auswirkungen auf neue Entwickler berücksichtigen (vielleicht eine PR zum Styleguide einreichen).

Deshalb mag ich den kürzeren "$vm"-Namen (Übrigens, warum muss er mit $ beginnen? :)

(Übrigens, warum muss es mit $ beginnen? :)

Winkeldefinierte Namen beginnen mit $ , wenn sie den Namensraum mit Programmiererdefinitionen teilen, wodurch Kollisionen vermieden werden. In diesem Fall wird es von Angular definiert und innerhalb des Bereichs definiert, in dem der Programmierer seine eigenen Definitionen haben kann. Durch die Verwendung $ vermeiden wir Namenskollisionen und Angular verhält sich konsequent so, wie Programmierer es erwarten.

(@johnpapa) Der Zweck dieses Styleguides ist es, eine Anleitung zum Erstellen von Angular-Anwendungen zu geben, indem er die Konventionen zeigt, die ich verwende, und, was noch wichtiger ist, warum ich sie wähle.

Stil Y032 Verwenden Sie hierfür eine Capture-Variable, wenn Sie die ControllerAs-Syntax verwenden. Wählen Sie einen konsistenten Variablennamen wie vm, was für ViewModel steht.

Es spielt also keine Rolle, ob es vm , ctrl oder troll ist, es muss nur eine konsistente Variable sein.
Darüber hinaus sollen, wie bereits erwähnt, keine neuen Konzepte hinzugefügt werden: vm steht für ViewModel , wenn Sie View Models nicht verwenden oder nicht damit vertraut sind, werden Sie es nicht verstehen wofür vm oder ViewModel steht, was verwirrend sein wird.

Ich bin kein Fan von verwirrenden Namen. Ich denke, ctrl ist verwirrend. Es ist Controller? Steuerung (wie HTML-Steuerung)? und ist das nicht für eine Komponente?

Ich stimme entweder für vm oder comp . vm wird häufig verwendet und ist leicht zu erklären. comp ist neu, aber nicht schwer zu erraten.

Wie wäre es mit $ctlr (dh ConTroLleR) statt $ctrl ?

+1 $komp

@petebacondarwin Oh, die Menge an Dyslektikern (wie ich selbst), die uns mit diesbezüglichen Problemen bombardieren werden ... :)

@drpicox Danke für die Erklärung, ich sehe deine Punkte und sie sind gültig. Es ist eine schwierige Frage, aber ich kann zumindest aus meiner Erfahrung sagen, dass ich keine Probleme hatte, Entwicklern die "vm" -Konvention beizubringen, und einigen Unternehmen geholfen habe, ihre massive App auf diese Weise zu strukturieren. Sie haben es ziemlich schnell verstanden, aber vielleicht habe ich' Ich bin allein mit dieser Erfahrung.

Aber ich verstehe deine Punkte. stimme $ zu

Ich bin zwar immer noch für $vm, aber mit $comp bin ich auch einverstanden ...

@wesleycho vom Angular UI Bootstrap-Team scheint stark gegen vm zu sein:
https://github.com/angular/angular.js/issues/10007#issuecomment -166707284

+1 für $ctrl

@shairez Ich teile deinen Standpunkt bezüglich einer Tagung voll und ganz, ich bin ein freiberuflicher Architekt mit Dutzenden von Projekten hinter mir, die vm Tagung hat sehr geholfen, aber ich habe immer noch einige Probleme. Es stellt sich heraus, dass es Leute gibt, die sich dagegen wehren, es zu benutzen. Wahrscheinlich sollte der Widerstand geringer sein, wenn diese Konvention von Angular selbst stammt, aber ich bin sicher, dass sie es ohne Widerstand akzeptieren würden, wenn der Name $ctrl wäre. $ctrl ist einfach geradlinig.

Die Stimmen sind also drin und es sieht so aus:

$comp  4
$cmp   2
$ctrl  19
$vm    3
$this  3
$ctx   2
$vc    1

Der klare Favorit ist $ctrl . Es ist nicht nur beliebt, sondern erfüllt auch die oben in dieser Ausgabe aufgeführten Kriterien. Außerdem führt es kein besonders neues Konzept ein. Das Ding, auf das verwiesen wird, ist wirklich ein Controller (ein Komponenten-/Direktiven-Controller), den Angular-Entwickler bereits verstehen, und so wie sich einige Entwickler daran gewöhnt haben, vm in ihren Direktiven zu verwenden, wird es nicht lange dauern, bis Entwickler sich daran gewöhnen auf diese Vorgabe.

Großartig, $ctrl ist es!

Problem für 1.4 und niedriger - kann kein 'als Name' mit $ctrl benennen

Ein weiteres Anliegen, das ich ansprechen möchte, ist, dass wir in Angle 1.4 und niedriger "als Namen" nicht wirklich verwenden können, beginnend mit einem $ -Zeichen.

Es gibt den folgenden Fehler:
Error: [$controller:ctrlfmt] Badly formed controller string

Einige Unternehmen haben Probleme beim Upgrade auf die neuesten Versionen, und es kann mehrere Monate dauern.

Sie wollen dennoch mit den Konventionen Schritt halten, damit ihr Upgrade-Prozess in Zukunft einfacher wird.

Für sie ist der Wechsel von vm zu $ctrl unmöglich.

Was denken Sie? irgendwelche Vorschläge?

vielleicht in Phasen migrieren:
Beginnen Sie mit der Umwandlung vm in ctrl
Wenn 1.5 veröffentlicht wird, "aktualisieren" Sie ctrl auf $ctrl

Ein anderer möglicher Weg – obwohl ausführlich – besteht darin, den Aliasnamen controllerAs in der Laufzeit zu generieren und angular.version zu überprüfen. etwas wie:

 angular
        .module('github')
        .directive('issueThread', issueThread);

    /* <strong i="14">@ngInject</strong> */
    function issueThread () {
        // this can be required as a module if using some module loader
        // or - another way is using global on angular namespace (i know it a bad practice - hwoever just to indicate reuse of this check 
        let prefix = angular.version.minor === 5 ? '$' : '';
        let controllerAs = prefix + 'ctrl';
        // with template strings
        var controllerAs = `${prefix}ctrl`;

        var directive = {
            controller: controller,
            restrict: 'E'
        };
        return directive;

        function controller() {
        }
    }

@orizens Was ist mit Vorlagen?

@shairez Uhmmm, es macht Sinn, $-Symbole sind nur für eckige Interna gedacht ... vielleicht ist es schön, eine Art Aufwärtskompatibilität im nächsten Minor zu haben.

@drpicox da hast du einen Punkt :).
Auch hier ist eine Lösung, die mir einfällt (hacky one ...), "ersetzen" Sie Strg durch $ Strg in der Vorlage in Runtime / Build. Dies kann leicht erreicht werden, wenn das Projekt mit es6 und Modulen erstellt wird. andernfalls ist es eine Aufgabe für gulp/grunt/npm zur Bauzeit.

Warum nicht einfach controllerAs verwenden?
Es ist keine ideale Lösung (und tatsächlich müssen wir möglicherweise die RegExp überarbeiten, die die Kennung aus der Controller-Zeichenfolge extrahiert (falls vorhanden), aber die Verwendung controllerAs ist sowohl rückwärts- als auch vorwärtskompatibel :)

(Wenn jemand versuchen möchte, diesen Bezeichner zu aktualisieren, der RegExp extrahiert, ist er übrigens genau dort .)

@gkalpak , das ist ein guter Punkt. Es ist gut, die Verwendung der Eigenschaft controllerAs voranzutreiben, da immer mehr Leute auch dazu übergehen werden, Komponenten in ihren Versionen 1.4 und niedriger zu verwenden, glaube ich.

Aber ich denke, es könnte verwirrend sein, wenn wir anfangen, den Leuten $ctrl , und in manchen Fällen funktioniert es und in manchen nicht.

Eine Aufwärtskompatibilität (nicht sicher wie) ist also eine großartige Idee!

@shairez hast du (kannst du) ein neues Problem erstellt, um dies zu verfolgen?

Ich habe #13736 erstellt, das $ als Bezeichner zulässt, wenn <ctrl> as <identifier> verwendet wird.
Dennoch unterscheiden sich die zulässigen Bezeichner zwischen controller: '... as ...' und controllerAs: '...' .

Allerdings bin ich mir nicht sicher, ob die Werbung für controller: '... as $ctrl' eine gute Möglichkeit ist, mit Konventionen Schritt zu halten. Es ist viel schwieriger, controller: '... as $ctrl' zu aktualisieren als controller: '...', controllerAs: '$ctrl' .

Danke @gkalpak - Ich stimme zu, dass wir wahrscheinlich die Verwendung der Eigenschaft controllerAs anstelle des Controllers als Syntax fördern sollten.

Eine Sache ist: Die Dokumentation der Komponente sagt: "Komponentendefinitionen sind sehr einfach und erfordern nicht viel von der Komplexität hinter der Definition allgemeiner Anweisungen".
Eine andere: Controller in Direktive ist nur notwendig, wenn Sie komplexe Direktiven bauen, die miteinander sprechen. Andernfalls ist eine Link-Funktion mehr als genug (z. B. "Controller verwenden, wenn Sie eine API anderen Anweisungen aussetzen möchten. Andernfalls Link verwenden" in der Richtlinie des Entwicklerhandbuchs und meiner Erfahrung nach Richtlinien, die dieselbe Funktionalität mit Link anstelle von Controllern implementieren, die einige hundert Mal verwendet werden in ng-repeat sind viel schneller.
Damit...
Ich finde in Component ("einfache" Direktive) nicht den Weg, "einfach" (Link-Funktion) zu machen, nur den schweren (Controller).
Verpasse ich etwas?
Danke für die Erklärung.

@frfancha - die Leistungsverbesserung ist darauf zurückzuführen, dass $injector nicht verwendet werden muss, um den Controller zu instanziieren, oder? Vielleicht haben Sie einige Leistungsmessungen, die Sie bereitstellen können?

Die Idee des Komponentenhelfers ist es, das Schreiben von Direktiven vom Komponententyp (isolate, element) einfacher (im Sinne von LOC) zu machen; und einfacher zu schreibender Code, der mehr in Einklang mit der Vorgehensweise in Angular 2 steht.

Wenn es in einer bestimmten App ein Leistungsproblem gibt, wäre es ziemlich einfach, eine Komponentendirektive umzuwandeln, um den allgemeineren directive -Helfer zu verwenden.

Ich denke, wir müssen uns die anderen API-Dokumente und Entwicklerleitfäden ansehen, um sicherzustellen, dass sie mit dem neuen component() -Hilfsprogramm übereinstimmen.

@petebacondarwin Am Anfang haben wir alle unsere Anweisungen mit Controller geschrieben, nur weil es im ersten Tutorial, dem wir gefolgt sind, so gezeigt wurde.
Erst nachdem wir festgestellt hatten, dass es ungefähr 15 Sekunden dauerte, eine bestimmte Seite mit 1000 Anweisungen (5 durch „Zeilen“ in ng-repeat x 200) zu „öffnen“, lasen wir mehr über Anweisungen und verstanden, dass Controller nutzlos sind, wenn Sie dies nicht tun. sprechen" zwischen Anweisungen (indem der Controller einer anderen angefordert wird). Nach dem "Umschreiben" aller mit Link-Funktionen anstelle von Controllern (Umschreiben ist ein großes Wort, da es nur das Kopieren/Einfügen des Codes in den Link anstelle des Controllers war), betrug die Zeit zum Anzeigen der Seite 8 Sekunden.
Beachten Sie, dass dies Firefox-Maßnahmen sind, zu diesem Zeitpunkt haben wir Chrome nicht verwendet. Jetzt verwenden wir es und ich schätze die Zeit in Chrome auf die dritte von Firefox (und die Speichernutzung auf die vierte (und ohne Speicherleck, was großartig ist, in Firefox ist unsere Anwendung bekanntermaßen "langsam am Nachmittag)).
Wir sind im Allgemeinen sehr zufrieden mit Angular (wir haben alle unsere Dateneingabeanwendungen von Smalltalk-Windows-Anwendung auf WEB API + Angular umgestellt (falls es Sie interessieren würde, es zu sehen?? Ich bin manchmal in London).
Aber ich bin überrascht von der Wahl des Controllers, um die "Simple Way"-to-Do-Direktive zu unterstützen

danke @gkalpak !

@petebacondarwin ein separates Problem ist nicht mehr relevant, oder? (Wegen PR)

Ich stimme zu (wie ich geschrieben habe), wir sollten die Leute dazu erziehen, die Eigenschaft controllerAs zu verwenden, aber ich habe es nur erwähnt, weil ich vorhersehe, dass Leute darauf stoßen werden.