Wir möchten die in Discourse verwendete Ember-Version aktualisieren.
Derzeit sind wir bei 3.15 und möchten zu 4.1 wechseln.
Wir haben uns zum Ziel gesetzt, diese Arbeiten bis Ende dieses Jahres abzuschließen. Bitte beachte, dass dieses Thema eine Roadmap ist und alle Pläne und Schätzungen vorläufig sind. Dieses Thema ist nicht dafür gedacht, umfangreiche Diskussionen über bestimmte Upgrades oder Änderungen aufzunehmen. Halten wir die Diskussion hier also etwas fokussiert. Fragen dazu, wie sich diese Updates auf deine Site/dein Plugin/dein Theme auswirken, sind Off-Topic. Die geplanten Änderungen betreffen zu 100 % das Frontend (Ember-App).
Wir werden bei den eingeführten Änderungen äußerst vorsichtig sein. Alle offiziellen Plugins/Themes werden aktualisiert (einschließlich jeglicher individueller Arbeit, die CDCK für seine Kunden geleistet hat). Wir werden auch PRs einreichen, um alle beliebten inoffiziellen Plugins/Themes zu aktualisieren.
Keine Sorge, wenn du ein benutzerdefiniertes Plugin/ein benutzerdefiniertes Theme hast, das du für deine Site erstellt hast. Wir werden Deprecation-Warnungen hinzufügen und rechtzeitig die notwendigen Ankündigungen treffen, um dir genug Zeit zu geben, alle erforderlichen Änderungen vorzunehmen. Wir werden dich bei Bedarf auch durch diese Änderungen führen.
Beginnen wir mit den Zielen. Wir wollen natürlich zur höchsten verfügbaren Version wechseln, aber wir müssen Zwischenziele zwischen jetzt und unserem Endziel setzen.
Wir planen inkrementelle Updates. Anstatt eines großen Updates auf 4.1 werden wir diese Arbeit in sechs Phasen aufteilen. Jede Phase konzentriert sich auf ein Ember-Update.
| Phase | Größe | Updates |
|---|---|---|
| 1 | size-l | Ember 3.15 → Ember 3.16 |
| 2 | size-m | Ember 3.16 → Ember 3.25 |
| 3 | size-xl | Ember 3.25 → Ember 3.26 (Teil 1 - Allgemein) Ember 3.25 → Ember 3.26 (Teil 2 - Templates) Ember 3.25 → Ember 3.26 (Teil 3 - jQuery) Ember 3.25 → Ember 3.26 (Teil 4 - Octane-Vorbereitung) Ember 3.25 → Ember 3.26 (Teil 5 - Octane) |
| 4 | size-l | Ember 3.26 → Ember 3.27 (Teil 1 - Allgemein) Ember 3.26 → Ember 3.27 (Teil 2 - RenderTemplate) Ember 3.26 → Ember 3.27 (Teil 3 - Legacy-eingebaute Komponenten) |
| 5 | size-s | Ember 3.27 → Ember 3.28 |
| 6 | size-s | Ember 3.28 → Ember 4.1 |
Die Auswahl dieser spezifischen Versionen basiert ausschließlich auf den Deprecations und dem Umfang der Arbeit, die sie mit sich bringen – und dem implizierten Risiko.
Also, lassen wir uns das für mehr Klarheit genauer ansehen.
Deprecations pro Update
Phase 1 (size-l)
Ember 3.15 → Ember 3.16
Dieses Update führt nur eine Deprecation ein.
-
Verwende ember-CLI-Resolver statt Legacy-Global-Resolver
- bis: 4.0.0 - size-lDiscourse hat einen eigenen benutzerdefinierten Resolver, der derzeit
Ember.DefaultResolvererweitert.Die empfohlene Lösung ist, alle benutzerdefinierten Resolver zu entfernen und den Ember-CLI Resolver zu verwenden. Das ist leichter gesagt als getan, da wir eine ganze Menge benutzerdefinierter Logik zur Handhabung von Plugins und Themes haben.
Ein Kompromiss, der funktioniert, ist, den Ember-CLI-Resolver zu erweitern, anstatt
Ember.DefaultResolverzu erweitern.
Phase 2 (size-m)
Ember 3.16 → Ember 3.25
Dieses Update führt acht Deprecations ein.
-
@ember/string#locund{{loc}} bis: 4.0.0 - 
-
Without for - Eingebaute Deprecation von Ember
bis: 4.0.0 - -
Without since - Eingebaute Deprecation von Ember
bis: 4.0.0 - -
tryInvoke aus @ember/utils
bis: 4.0.0 - -
Meta-Destruction-APIs
- bis: 3.25.0 - Wir verwenden keine davon, also gibt es hier nichts zu tun.
-
Verwende Ember-Getter und prüfe explizit auf undefined - bis: 4.0.0 - size-sDies ist eine einfache Deprecation. Wir müssen nurgetWithDefaultin unserem Codebase entfernen, und es gibt nur wenige Stellen, an denen wir es verwenden. -
String-Prototyp-Erweiterungen - bis: 4.0.0 - size-mDies ist auch ein einfacher, risikoarmer Austausch, aber wir verwenden Embers erweiterten String-Prototyp an ziemlich vielen Stellen. Bei einer schnellen Überprüfung glaube ich, dass wir etwa < 100 Stellen haben, an denen wir das zwischen Core und Plugins/Themes tun.Sobald wir diese aktualisiert haben, sollten wir Ember auch davon abhalten, diesen Prototyp mit etwas wie diesem zu erweitern.EXTEND_PROTOTYPES: { String: false }in unserer environment Datei.
-
Importieren vonhtmlSafeundisHTMLSafeaus @ember/string - bis: 4.0.0 - size-mHier gibt es viel Überschneidung mit #7 in diesem Update, und es sollte straightforward und risikoarm sein.
Phase 3 (size-xl)
Das Upgrade von 3.25 auf 3.26 ist ziemlich aufwendig. Hier holen wir den Großteil des „Nachholens“ ein. Es gibt insgesamt sechzehn Deprecations. Wir werden dieses Update in fünf Teile aufteilen – wobei wir erst nach der Bearbeitung aller Deprecations eine Versionsänderung vornehmen.
Ember 3.25 → Ember 3.26 (Teil 1 - Allgemein)
Dieser Teil befasst sich mit neun Deprecations, die relativ einfacher zu handhaben sind.
-
Array-Observers
- bis: 4.0.0 - -
Komponenten-Manager-Fähigkeiten
- bis: 4.0.0 - -
Modifier-Manager-Fähigkeiten
- bis: 4.0.0 - -
Optionale Funktion: application-template-wrapper
- bis: 4.0.0 - -
classBinding und classNameBindings als Argumente in Templates
- bis: 4.0.0 - Hier gibt es nichts zu tun; wir verwenden diese nicht.
-
Übergangsmethoden von Routen und Controllern
- bis: 5.0.0 - size-mDiese Deprecation entfernt ein paar Methoden aus
routesundcontrollers. Es mag wie eine aufwendige Änderung aussehen, aber sie sollte straightforward sein. Wir müssten nur denRouterals Service injizieren und sie von dort aus aufrufen – wenn erforderlich. Der schwierige Teil ist, dass wir diese an vielen Stellen verwenden, und alle müssen aktualisiert werden. -
Browser-Support-Richtlinie - bis: 4.0.0 - size-s~~Dies sollte eine relativ einfache Änderung sein. Ember wird ab 4.0 keinen Support für IE11 mehr bieten. Das Schöne daran ist, dass wir es ohnehin schon seit langer Zeit nicht unterstützen. Das Einzige, was wir ändern müssen, ist, die Transpilation für IE11 in der Produktion zu stoppen.
discourse/app/assets/javascripts/discourse/config/targets.js at 1472e47aae5bfdfb6fd9abfe89beb186c751f514 · discourse/discourse · GitHubIch habe einige grundlegende Tests durchgeführt, und diese Änderung wird uns etwa 60kb (gzip) oder ~6 % unserer Haupt- und Vendor-Bundles in Produktions-Ember-CLI-Installationen sparen. -
{{hasBlock}} und {{hasBlockParams}} - bis: 4.0.0 - size-sWir verwenden diese an ein paar Stellen. Dies ist eine einfache, risikoarme Umbenennung. -
{{with}}-Helper - bis: 4.0.0 - size-sWir verwenden diesen selten, aber er muss dennoch behoben werden. Wir müssen sie nur austauschen und{{let}}oder eine Kombination aus{{if}}/{{else}}verwenden
Ember 3.25 → Ember 3.26 (Teil 2 - Templates)
Dieser Teil wird sich hauptsächlich auf Deprecations konzentrieren, die .hbs-Templates betreffen. Hier gibt es drei Deprecations, auf die wir uns konzentrieren müssen.
-
Eigenschafts-Fallback-Suche
- bis: 4.0.0 - size-lAb Ember 4.0 wird dies nicht mehr funktionieren.
Hallo, {{name}}!Wenn wir eine Eigenschaft in einem Template haben, müssen wir sie mit einem vorangestellten
thiswie folgt suchenHallo, {{this.name}}!Das müssten wir mit all unseren Templates machen. Es gibt Möglichkeiten, den Schmerz hier zu reduzieren. Wir können versuchen, den ember-no-implicit-this-codemod zu verwenden und sehen, wie weit er uns bringt.
Ich bin dafür, Änderungen auf 1 Datei pro PR zu beschränken. Das macht es einfach zu überprüfen – und zurückzusetzen, wenn etwas schiefgeht.
-
Zugriff auf benannte Argumente über {{attrs}}
- bis: 4.0.0 size-xlDas
{{attrs}}-Objekt wird in Ember 4.0 entfernt. Die Änderung selbst ist sehr straightforward, und Embers Beispiel ist ganz nett.Vorher:
{{attrs.foo}} {{this.attrs.foo.bar}} {{deeply (nested attrs.foobar.baz)}}Nachher:
{{@foo}} {{@foo.bar}} {{deeply (nested @foobar.baz)}}Das müssten wir für all unsere Templates tun. Wir können diese Änderung mit der Konvertierung der Templates in die Winkelklammer-Syntax kombinieren. Ich bin ein großer Fan von Winkelklammern, weil sie viel näher an der Standard-Syntax für benutzerdefinierte Web-Komponenten sind.
Etwas, das unseren Fortschritt hier beschleunigen könnte, ist der ember-angle-brackets-codemod. Wir müssen damit experimentieren und sehen, wie weit er uns bringt. Er behandelt die Deprecation und gibt uns die schicke Winkelklammer-Syntax.
Ähnlich wie bei #1 in diesem Teil bevorzuge ich auch, Template für Template zu reparieren und zu testen, und zwar pro PR.
-
<LinkTo>-Positional-Argumente - bis: 4.0.0 - size-mDies ist auch eine Deprecation, die darauf abzielt, Verwirrung zu reduzieren. Es gibt ein paar Stellen, an denen wir Positional-Argumente bei link-to verwenden. Wir können diese wie folgt beheben
Vorher:
{{link-to "Über uns" "about"}} {{#link-to "about"}}Über uns{{/link-to}} {{#link-to "post" @post}}Lesen {{@post.title}}...{{/link-to}}Nachher (mit Winkelklammern):
<LinkTo @route="about">Über uns</LinkTo> <LinkTo @route="about">Über uns</LinkTo> <LinkTo @route="post" @model={{@post}}>Lesen {{@post.title}}...</LinkTo>
Ember 3.25 → Ember 3.26 (Teil 3 - jQuery)
Da gibt es nicht viel zu sagen, was du nicht schon weißt. Neue Ember-Apps verwenden kein jQuery, und es wird in Ember 4.0 entfernt.
In diesem Teil konzentrieren wir uns auf eine Deprecation.
-
Optionale Funktion: jquery-integration
- bis: 4.0.0 - size-xlIn den letzten Jahren haben wir enorme Fortschritte bei der Reduzierung unserer jQuery-Nutzung gemacht. Es gibt immer noch Stellen, an denen wir es brauchen, insbesondere im Composer und als Abhängigkeit für einige Vendor-Bibliotheken, die wir verwenden. Ich will hier nicht auf die Details dieser Änderung eingehen. Kurz gesagt, wir sollten uns von der Verwendung von jQuery verabschieden.
Ich möchte jedoch hervorheben, dass wir diese Option auch dann auf true setzen sollten, wenn wir jQuery ÜBERALL entfernen, bis wir für Ember 4.0 bereit sind. Wir brauchen einen Plan, um den Übergang für Sites mit benutzerdefinierten Themes/Plugins, die wir nicht kontrollieren, zu erleichtern. Mit anderen Worten: Lassen wir die Arbeit erledigen, aber leben wir mit der Deprecation-Warnung darüber, die Option auszuschalten.
Ember 3.25 → Ember 3.26 (Teil 4 - Octane-Vorbereitung)
In diesem Teil sollten wir uns darauf konzentrieren, unsere Dateien für Octane vorzubereiten. Wir werden zwei Deprecations bearbeiten.
-
Optionale Funktion: template-only-glimmer-components
- bis: 4.0.0 - size-mTheoretisch ist dies eine einfache Änderung, aber es gibt implizite Arbeit, die wir leisten müssen, bevor wir diese Option umschalten können.
Wir müssen sicherstellen, dass unsere aktuellen template-only-Komponenten mit Glimmer-Semantik funktionieren. Ich habe einige Tests durchgeführt, und unsere Tests sind mit dieser Option aktiviert gescheitert. Hier ist eine Beispiel-Liste einiger template-only-Komponenten, die wir im Core haben
- app/templates/components/activation-email-form.hbs - app/templates/components/cancel-link.hbs - app/templates/components/categories-with-featured-topics.hbs - app/templates/components/category-name-fields.hbs - app/templates/components/color-input.hbs - app/templates/components/custom-html-container.hbs - app/templates/components/emoji-group-buttons.hbs - app/templates/components/emoji-group-sections.hbs - app/templates/components/empty-state.hbs - app/templates/components/ip-lookup.hbs - app/templates/components/modal-footer-close.hbs - app/templates/components/popup-menu.hbs - app/templates/components/reviewable-created-by-name.hbs - app/templates/components/reviewable-created-by.hbs - app/templates/components/reviewable-field-editor.hbs - app/templates/components/reviewable-field-text.hbs - app/templates/components/reviewable-field-textarea.hbs - app/templates/components/reviewable-field.hbs - app/templates/components/reviewable-flagged-post.hbs - app/templates/components/reviewable-post-header.hbs - app/templates/components/reviewable-post.hbs - app/templates/components/reviewable-scores.hbs - app/templates/components/reviewable-tags.hbs - app/templates/components/reviewable-topic-link.hbs - app/templates/components/score-value.hbs - app/templates/components/selected-posts.hbs - app/templates/components/subcategories-with-featured-topics.hbs - app/templates/components/text-overflow.hbs - app/templates/components/user-fields/confirm.hbs - app/templates/components/user-fields/dropdown.hbs - app/templates/components/user-fields/multiselect.hbs - app/templates/components/user-fields/text.hbs - app/templates/components/user-profile-avatar.hbs - app/templates/components/user-summary-users-list.hbsWir müssen auch unsere Admin/Theme/Plugin-Templates überprüfen und sicherstellen, dass alles funktioniert, bevor wir diese Option ausliefern.
Mir ist nicht ganz klar, wie unsere rohen
.hbr-Templates hier hineinpassen werden. Allerdings hat @david an glimmer-basierten Themenlisten gearbeitet. Vielleicht können wir rohe Templates ganz abschaffen. -
Implizite Injektionen
- bis: 4.0.0 size-xlWir verwenden implizite Injektionen überall. Wir tun dies in einem Initializer wie folgt
discourse/app/assets/javascripts/discourse/app/pre-initializers/inject-discourse-objects.js at ac79c5efc61d259705eeb487ca21d0ec3c535807 · discourse/discourse · GitHubEmber verabschiedet sich von impliziten Injektionen. Der bevorzugte Weg ist, so viele unserer Objekte wie möglich in Services umzuwandeln und sie explizit dort zu injizieren, wo sie benötigt werden. Natürlich gibt es vielleicht ein paar Dinge, bei denen ein Service nicht ideal ist. In diesen Fällen können wir diese Objekte direkt nachschlagen, wenn sie benötigt werden, wie folgt
getOwner(this).lookup('thing:main')Eine weitere Option, die wir haben (je nach Performance-Auswirkungen), ist, die Ember-Klassen mit unserer eigenen Discourse-Klasse zu umschließen. Wir würden dann unsere Klasse in der gesamten App verwenden. Ähnlich wie wir es mit der
GlimmerComponent Classtun
discourse/app/assets/javascripts/discourse/app/components/glimmer.js at fa0c796baf9a7f64a3b27823b1aa4b370a74c3eb · discourse/discourse · GitHub. Dies würde diese Aufgabe zu einer size-l oder sogar size-m machenAuf jeden Fall wird diese Änderung etwas Nachdenken erfordern.
Ember 3.25 → Ember 3.26 (Teil 5 - Octane)
Dies ist die letzte Etappe des 3.25 → Ember 3.26 Upgrades. Wir werden zu diesem Zeitpunkt nur noch eine Deprecation haben, aber sie ist eine große.
-
Edition: Classic
- bis: 4.0.0 - size-xlBevor wir unsere Version auf Octane umschalten können, möchte ich Zeit damit verbringen, unsere Klassen in native Klassen und unsere Komponenten in Glimmer-Komponenten umzuwandeln. Es wird ein bisschen Schmerz geben, aber es lohnt sich. Der ember-native-class-codemod sollte etwas von diesem Schmerz lindern. Wir werden sehen, wie weit er uns bringt.
Es gibt viele Überlegungen und Workflow-Probleme, die man im Auge behalten muss. Das Einzige, was ich hervorheben möchte, ist, dass es dem gleichen Fluss folgen wird, den ich für Templates erwähnt habe – repariere und teste 1 Komponente pro PR.
Phase 4
Das Ember 3.26 → Ember 3.27 Update führt zwölf Deprecations ein. Ich schlage vor, wir teilen sie in drei Teile auf. Wir werden die Versionsänderung vornehmen, nachdem alle Deprecations bearbeitet wurden.
Ember 3.26 → Ember 3.27 (Teil 1 - Allgemein)
-
Wiedereröffnung der Classic-Komponenten-Superklasse
- bis: 4.0.0 - -
Klassenbasierte Template-Kompilierungs-Plugins
- bis: 4.0.0 - -
LinkTo @disabled-when-Argument
- bis: 4.0.0 - Ich glaube nicht, dass wir irgendeines davon verwenden, also gibt es hier nichts zu tun.
-
Deprecate
Route#disconnectOutlet - bis: 4.0.0 - size-sWir tun dies nur an einer Stelle. Es ist die
build-category-route, und es sollte straightforward sein, es zu beheben. -
Aufrufen von Helfern ohne Argumente und Klammern in benannten Argumentpositionen
- bis: 4.0.0 - size-sIch glaube nicht, dass wir das irgendwo tun, aber ich werde es bestätigen, wenn die Zeit kommt. Im Wesentlichen den Aufruf eines Helfers, ohne ihm irgendwelche Argumente zu übergeben.
Selbst wenn wir so etwas verwenden, müssten wir nur Klammern hinzufügen. Also, dies
<SomeComponent @arg={{someHelper}} />wird zu
<SomeComponent @arg={{(someHelper)}} />beachte die Klammern um
someHelper -
Run loop und computed dot access
- bis: 4.0.0 - size-mWir verwenden
., um aufcomputed-Funktionen in unseremdecorators-Addon zuzugreifen. Sie sehen zum Beispiel so aus
discourse/app/assets/javascripts/discourse-common/addon/utils/decorators.js at b05fddaa7ce3968ffc70cd8d4bf290e15d06eb11 · discourse/discourse · GitHubWir haben auch hier und da ein paar einsame Einzelfälle. Soweit ich das beurteilen kann, geht es beim Beheben dieser hauptsächlich darum, zu korrigieren, wie wir sie importieren.
Also,
computed.filtersollte stattdessen so importiert werden.import { filter } from '@ember/object/computed';Unsere Version des externen Vendor-Addons
buffered-proxyverwendet., um aufcomputed-Funktionen zuzugreifen; wir müssten es bumpen.Wir verwenden auch
., um an ein paar Stellen aufrun-Funktionen zuzugreifen. Das heißt, die gleiche Korrektur gilt. Wir müssen aktualisieren, wie wir sie importieren. Ich denke, Themes und Plugins haben besonders ziemlich viele Stellen, an denen wir das mitruntun. -
Deprecate das Ember-Global
- bis: 4.0.0 - (#size ?)Emberwird nach 4.0 nicht mehr im globalen Kontext verfügbar sein. Es ist schwierig, den Arbeits-/Auswirkungsumfang hier ohne einen tieferen Blick zu schätzen. Das gesagt, ich weiß, dass @cvx eine Menge Arbeit leistet, um dieses Muster zu beseitigen.
Ember 3.26 → Ember 3.27 (Teil 2 - renderTemplate)
Dieser Teil wird sich nur auf eine Deprecation konzentrieren.
-
Deprecate
Route#renderTemplate - bis: 4.0.0 - size-lKurz gesagt, wir können in Ember 4.0 keine benannten Outlets mehr verwenden. Also, dies wird nicht funktionieren.
{{outlet "thing"}}Wir verwenden
renderTemplateallein im Core an fast 30 Stellen. Das Upgrade selbst scheint ziemlich straightforward zu sein. Wir können{{#in-element}}und ein leeres HTML-Element als Platzhalter für das verwenden, was wir früher in benannten Outlets gerendert haben.
Ember 3.26 → Ember 3.27 (Teil 3 - Legacy-eingebaute Komponenten)
Dieser Teil wird sich auf eingebaute Legacy-Komponenten konzentrieren und vier Deprecations bearbeiten.
- Importieren von Legacy-eingebauten Komponenten - bis: 4.0.0
- Eingebaute Komponenten Legacy-Argumente - bis: 4.0.0
- Eingebaute Komponenten Legacy-HTML-Attribut-Argumente - bis: 4.0.0
- Wiedereröffnung von Legacy-eingebauten Komponenten - bis: 4.0.0
Ich habe keine Größen hinzugefügt, weil… es wirklich darauf ankommt. Lassen Sie mich erklären.
Legacy-eingebaute Komponenten wie Checkbox, TextField, TextArea und LinkComponent werden in Ember 4.0 entfernt. Wir verwenden sie an ziemlich vielen Stellen, und wir verwenden auch einige veraltete Muster darauf.
Ember bietet einen Upgrade-Pfad, der es uns ermöglicht, sie weiterzuverwenden, aber wir müssen sie anders importieren. Sie werden jedoch keine Updates von Ember erhalten und bleiben eingefroren. Ich hoffe, dass wir uns von allen verabschieden können; das könnte jedoch etwas aufwendig sein. Diese Änderung wird mehr Diskussion erfordern, wenn die Zeit kommt.
Phase 5
Ember 3.27 → Ember 3.28
Dies ist ein size-s, da es nur ein Versions-Bump ist. 3.28 ist die letzte LTS-Version im 3.x-Entwicklungszyklus. Sie führt keine neuen Deprecations nach 3.27 ein, und es ist eine gute Version, um für ein paar Wochen innezuhalten, während sich die Dinge beruhigen.
3.28 LTS wird bis August 2022 unterstützt (sowohl Bugfixes als auch Sicherheitspatches)
Diese “Pause” hat einige Vorteile.
- Sie gibt uns mehr Zeit, um zu sehen, ob Probleme auftreten
- Wenn wir eine stabile Version ausliefern, sollte sie auf 3.28 sein
- Sie gibt uns Zeit, um alle notwendigen Ankündigungen bezüglich selbst gewarteter Themes und Plugins zu machen
- Sie gibt uns Zeit, um sicherzustellen, dass der Übergang von jQuery zu kein jQuery so reibungslos wie möglich ist.
Phase 6
Nach ein paar Wochen können wir unsere Version endlich auf Ember 4 bumpen
Ember 3.28 → Ember 4.1
Wir können jetzt die optionale jQuery-Integration als letzte Deprecation aus dem 3.x-Zyklus ausschalten.
Dieses Update führt zwei geringfügige Deprecations ein.
-
Deprecate Ember.assign - bis: 5.0.0 - size-sWir verwenden das nicht im Core, aber wir müssen Themes/Plugins überprüfen. Auf jeden Fall ist es eine einfache Umbenennung. -
AutoLocation-Klasse
- bis: 5.0.0 - size-sTheoretisch müssten wir nur
locationType: 'auto'inlocationType: 'history'in unserer Ember-Umgebungsdatei ändern, und es sollte einfach funktionieren.
Workflow
Wie ich am Anfang erwähnt habe, werden wir bei diesen Updates sehr vorsichtig sein. Wir werden alle offiziellen Plugins/Themes mit jedem Update testen/fixen/pinnen, und wir werden auch PRs an beliebte inoffizielle Plugins/Themes senden.
Das Ziel hier ist nicht, die Entwicklung zu verlangsamen oder Kopfschmerzen zu verursachen. Also, die PRs sollten streng umrissen sein, mit einer Änderung pro PR und nichts zu Großem.
In einer idealen Welt würden all diese Änderungen im Hintergrund stattfinden, ohne die Arbeit anderer zu unterbrechen. Deshalb planen wir, die PRs kurz und knackig zu halten. Außerdem sind wir nicht sehr an gemischten Mustern interessiert. Also, wir wollen nicht in einem Zwischenzustand auf Dateiebene stecken bleiben. Eine Komponente ist entweder classic oder Glimmer, und ein Template verwendet entweder geschweifte Klammern oder Winkelklammern, nichts dazwischen.
Ich hoffe, diese Roadmap war klar. Wie ich am Anfang erwähnt habe, ist dies nur eine allgemeine oberste Übersicht. Wenn etwas unklar, falsch oder nicht in Ordnung ist, lass es uns bitte wissen.
)?
