Nous souhaitons mettre à jour la version d’Ember utilisée dans Discourse.
Actuellement, nous sommes à la version 3.15, et nous aimerions passer à la version 4.1.
Nous nous sommes fixé pour objectif de terminer ce travail d’ici la fin de l’année. Veuillez noter que ce sujet constitue une feuille de route, et que tous les plans et estimations sont indicatifs. Ce sujet n’a pas pour but d’accueillir des discussions approfondies sur des mises à jour ou des changements particuliers. Gardons donc la conversation ici un peu ciblée. Les questions sur la façon dont ces mises à jour affecteront votre site/plugin/thème sont hors sujet. Les changements prévus concernent à 100 % le front-end (application Ember).
Nous ferons extrêmement attention aux changements que nous introduisons. Tous les plugins/thèmes officiels seront mis à jour (y compris tout travail personnalisé réalisé par CDCK pour ses clients). Nous enverrons également des PR pour mettre à jour tous les plugins/thèmes non officiels populaires.
Pas de souci si vous avez un plugin/thème personnalisé que vous avez créé pour votre site. Nous ajouterons des avertissements de dépréciation et créerons les annonces nécessaires en temps opportun pour vous donner suffisamment de temps pour effectuer les modifications requises. Nous essaierons également de vous guider dans ces changements si nécessaire.
Commençons par les objectifs. Nous voulons évidemment atteindre la version la plus récente disponible, mais nous devons définir des objectifs intermédiaires entre maintenant et notre destination finale.
Nous prévoyons de faire des mises à jour incrémentielles. Au lieu d’une mise à jour majeure vers 4.1, nous allons diviser ce travail en six étapes. Chaque étape se concentre sur une mise à jour Ember.
| Étape | Taille | Mises à jour |
|---|---|---|
| 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 (Partie 1 - Général) Ember 3.25 → Ember 3.26 (Partie 2 - Modèles) Ember 3.25 → Ember 3.26 (Partie 3 - jQuery) Ember 3.25 → Ember 3.26 (Partie 4 - Travaux préparatoires Octane) Ember 3.25 → Ember 3.26 (Partie 5 - Octane) |
| 4 | size-l | Ember 3.26 → Ember 3.27 (Partie 1 - Général) Ember 3.26 → Ember 3.27 (Partie 2 - RenderTemplate) Ember 3.26 → Ember 3.27 (Partie 3 - Composants intégrés hérités) |
| 5 | size-s | Ember 3.27 → Ember 3.28 |
| 6 | size-s | Ember 3.28 → Ember 4.1 |
Le choix de ces versions spécifiques est entièrement basé sur les dépréciations et la quantité de travail qu’elles introduisent - et le risque implicite.
Décomposons-les donc davantage pour plus de clarté.
Dépréciations par mise à jour
Étape 1 (size-l)
Ember 3.15 → Ember 3.16
Cette mise à jour n’introduit qu’une dépréciation.
-
Utiliser le résolveur ember-CLI plutôt que le résolveur global hérité
- jusqu’à : 4.0.0 - size-lDiscourse possède son propre résolveur personnalisé qui étend actuellement
Ember.DefaultResolver.La correction recommandée consiste à se passer de tout résolveur personnalisé et à utiliser le résolveur Ember-CLI. C’est plus facile à dire qu’à faire car nous avons pas mal de logique personnalisée pour gérer les plugins et les thèmes.
Un compromis qui fonctionne consiste à étendre le résolveur Ember-CLI plutôt que d’étendre
Ember.DefaultResolver.
Étape 2 (size-m)
Ember 3.16 → Ember 3.25
Cette mise à jour introduit huit dépréciations.
-
@ember/string#locet{{loc}} jusqu’à : 4.0.0 - 
-
Without for - Dépréciation intégrée d’Ember
jusqu’à : 4.0.0 - -
Without since - Dépréciation intégrée d’Ember
jusqu’à : 4.0.0 - -
tryInvoke from @ember/utils
jusqu’à : 4.0.0 - -
Meta Destruction APIs
- jusqu’à : 3.25.0 - Nous n’utilisons aucun de ceux-ci, donc il n’y a rien à faire ici.
-
Utiliser Ember getter et vérifier explicitement pour undefined - jusqu’à : 4.0.0 - size-sC’est une dépréciation simple. Nous devons simplement supprimergetWithDefaultdans notre base de code, et il n’y a que quelques endroits où nous l’utilisons. -
Extensions de prototype de chaîne - jusqu’à : 4.0.0 - size-mC’est aussi un remplacement simple et à faible risque, mais nous utilisons le prototype de chaîne étendu d’Ember en assez d’endroits. D’après une vérification rapide, je pense que nous avons environ < 100 endroits où nous faisons cela entre le noyau et les plugins/thèmes.Une fois que nous aurons mis à jour ceux-ci, nous devrons également empêcher Ember d’étendre ce prototype avec quelque chose comme ceci.EXTEND_PROTOTYPES: { String: false }dans notre fichier environment.
-
Importation dehtmlSafeetisHTMLSafedepuis @ember/string - jusqu’à : 4.0.0 - size-mIl y a beaucoup de chevauchement entre cela et #7 dans cette mise à jour, et cela devrait être simple et à faible risque.
Étape 3 (size-xl)
La mise à niveau de 3.25 à 3.26 est assez complexe. C’est là que nous faisons la plupart du “rattrapage”. Il y a seize dépréciations au total. Nous allons diviser cette mise à jour en cinq parties - où nous ne faisons qu’une augmentation de version après que toutes les dépréciations ont été traitées.
Ember 3.25 → Ember 3.26 (Partie 1 - Général)
Cette partie traite de neuf dépréciations qui sont relativement faciles à gérer.
-
Observateurs de tableau
- jusqu’à : 4.0.0 - -
Capacités du gestionnaire de composants
- jusqu’à : 4.0.0 - -
Capacités du gestionnaire de modificateurs
- jusqu’à : 4.0.0 - -
Fonctionnalité optionnelle : application-template-wrapper
- jusqu’à : 4.0.0 - -
classBinding et classNameBindings en tant qu’arguments dans les modèles
- jusqu’à : 4.0.0 - Rien à faire ici ; nous n’utilisons pas ceux-ci.
-
Méthodes de transition des routes et contrôleurs
- jusqu’à : 5.0.0 - size-mCette dépréciation supprime quelques méthodes des
routesetcontrollers. Cela peut sembler être un changement complexe, mais cela devrait être simple. Nous devrons simplement injecter leRouteren tant que service et les appeler depuis là-bas - si nécessaire. La partie délicate est que nous les utilisons en de nombreux endroits, et ils doivent tous être mis à jour. -
Politique de support des navigateurs - jusqu’à : 4.0.0 - size-s~~Ce devrait être un changement relativement simple. Ember ne supportera plus IE11 à partir de 4.0. La bonne chose ici est que nous ne le supportons plus depuis longtemps de toute façon. La seule chose que nous devons changer est d’arrêter de transpiler pour IE11 en production.
discourse/app/assets/javascripts/discourse/config/targets.js at 1472e47aae5bfdfb6fd9abfe89beb186c751f514 · discourse/discourse · GitHubJ’ai fait quelques tests de base, et ce changement nous fera économiser environ 60ko (gzip) ou ~6% de nos bundles principaux et fournisseurs dans les installations Ember-CLI en production. -
{{hasBlock}} et {{hasBlockParams}} - jusqu’à : 4.0.0 - size-sNous les utilisons en quelques endroits. C’est un renommage simple et à faible risque. -
Assistant{{with}} - jusqu’à : 4.0.0 - size-sNous l’utilisons rarement, mais il faut quand même le corriger. Nous devons simplement les remplacer et utiliser{{let}}ou une combinaison de{{if}}/{{else}}
Ember 3.25 → Ember 3.26 (Partie 2 - Modèles)
Cette partie se concentrera principalement sur les dépréciations impliquant les modèles .hbs. Il y a trois dépréciations sur lesquelles nous devons nous concentrer ici.
-
Recherche de repli de propriété
- jusqu’à : 4.0.0 - size-lÀ partir d’Ember 4.0, cela ne fonctionnera plus.
Bonjour, {{name}} !Si nous avons une propriété dans un modèle, nous devons la rechercher avec un
thisprécédent comme ceciBonjour, {{this.name}} !Nous devrons faire cela pour tous nos modèles. Il y a des moyens de réduire la douleur ici. Nous pouvons essayer le ember-no-implicit-this-codemod et voir jusqu’où cela nous mène.
Je suis en faveur de limiter les changements à 1 fichier par PR. Cela facilite la revue - et l’annulation si quelque chose se passe mal.
-
Accès aux arguments nommés via {{attrs}}
- jusqu’à : 4.0.0 size-xlL’objet
{{attrs}}sera supprimé dans Ember 4.0. Le changement lui-même est très simple, et l’exemple d’Ember est plutôt agréable.Avant :
{{attrs.foo}} {{this.attrs.foo.bar}} {{deeply (nested attrs.foobar.baz)}}Après :
{{@foo}} {{@foo.bar}} {{deeply (nested @foobar.baz)}}Nous devrons faire cela pour tous nos modèles. Nous pouvons combiner ce changement avec la conversion des modèles en syntaxe à chevrons. Je suis un grand fan des chevrons car ils sont beaucoup plus proches de la syntaxe standard des composants web personnalisés.
Une chose qui pourrait accélérer notre progression ici est le ember-angle-brackets-codemod. Nous devrons expérimenter avec cela et voir jusqu’où cela nous mène. Il gère la dépréciation et nous donne une belle syntaxe à chevrons.
Similaire à #1 dans cette partie, je préfère également corriger et tester un modèle par PR.
-
Arguments positionnels
<LinkTo> - jusqu’à : 4.0.0 - size-mC’est aussi une dépréciation qui vise à réduire la confusion. Il y a quelques endroits où nous utilisons des arguments positionnels sur link-to. Nous pouvons les corriger comme ceci
Avant :
{{link-to "À propos de nous" "about"}} {{#link-to "about"}}À propos de nous{{/link-to}} {{#link-to "post" @post}}Lire {{@post.title}}...{{/link-to}}Après (avec chevrons) :
<LinkTo @route="about">À propos de nous</LinkTo> <LinkTo @route="about">À propos de nous</LinkTo> <LinkTo @route="post" @model={{@post}}>Lire {{@post.title}}...</LinkTo>
Ember 3.25 → Ember 3.26 (Partie 3 - jQuery)
Il n’y a pas grand-chose que je puisse dire à ce sujet que vous ne sachiez déjà. Les nouvelles applications Ember n’utilisent pas jQuery, et il sera supprimé dans Ember 4.0.
Dans cette partie, nous nous concentrerons sur une dépréciation.
-
Fonctionnalité optionnelle : jquery-integration
- jusqu’à : 4.0.0 - size-xlAu cours des dernières années, nous avons fait beaucoup de progrès pour réduire notre utilisation de jQuery. Il y a encore des endroits où nous en avons besoin, en particulier dans le compositeur et comme dépendance pour certaines bibliothèques fournisseurs que nous utilisons. Je ne veux pas entrer dans les détails de ce changement ici. En bref, nous devrons nous éloigner de l’utilisation de jQuery.
Cependant, je voudrais souligner que même si nous nous débarrassons de jQuery PARTOUT, nous devrions quand même garder cette option définie sur true jusqu’à ce que nous soyons prêts pour Ember 4.0. Nous avons besoin d’un plan pour faciliter la transition des sites avec des thèmes/plugins personnalisés que nous ne contrôlons pas. En d’autres termes, faisons le travail mais vivons avec l’avertissement de dépréciation concernant la désactivation de l’option.
Ember 3.25 → Ember 3.26 (Partie 4 - Travaux préparatoires Octane)
Dans cette partie, nous devrions nous concentrer sur la préparation de nos fichiers pour Octane. Nous traiterons deux dépréciations.
-
Fonctionnalité optionnelle : template-only-glimmer-components
- jusqu’à : 4.0.0 - size-mC’est un changement simple en théorie, mais il y a du travail implicite que nous devons faire avant de pouvoir basculer cette option.
Nous devons nous assurer que nos composants actuels basés uniquement sur des modèles fonctionnent avec la sémantique Glimmer. J’ai fait quelques tests, et nos tests ont échoué avec cette option activée. Voici une liste exemple de certains composants basés uniquement sur des modèles que nous avons dans le noyau
- 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.hbsNous devrons également vérifier nos modèles Admin/thème/plugin et nous assurer que tout fonctionne avant de publier cette option.
Au premier abord, je ne suis pas exactement sûr de la façon dont nos modèles
.hbrbruts s’intégreront à cela. Cependant, @david a travaillé sur des listes de sujets basées sur Glimmer. Donc, peut-être pouvons-nous nous passer complètement des modèles bruts. -
Injections implicites
- jusqu’à : 4.0.0 size-xlNous utilisons des injections implicites partout. Nous faisons cela dans un initialiseur comme ceci
discourse/app/assets/javascripts/discourse/app/pre-initializers/inject-discourse-objects.js at ac79c5efc61d259705eeb487ca21d0ec3c535807 · discourse/discourse · GitHubEmber s’éloigne des injections implicites. La voie privilégiée est de convertir autant de nos objets que possible en services et de les injecter explicitement là où ils sont nécessaires. Bien sûr, il pourrait y avoir quelques choses où un service n’est pas idéal. Dans ces cas, nous pouvons rechercher ces objets directement lorsqu’ils sont nécessaires comme ceci
getOwner(this).lookup('thing:main')Une autre option que nous avons (selon les implications de performance) est d’encapsuler les Classes Ember avec notre propre Classe Discourse. Nous utiliserions ensuite notre Classe dans toute l’application. Un peu comme nous le faisons avec la
Classe GlimmerComponent
discourse/app/assets/javascripts/discourse/app/components/glimmer.js at fa0c796baf9a7f64a3b27823b1aa4b370a74c3eb · discourse/discourse · GitHub. Cela rendrait cette tâche size-l ou même size-mDans tous les cas, ce changement nécessitera une réflexion.
Ember 3.25 → Ember 3.26 (Partie 5 - Octane)
C’est le dernier sprint de la mise à niveau 3.25 → Ember 3.26. Nous n’aurons qu’une dépréciation restante à ce stade, mais c’en est une importante.
-
Édition : Classic
- jusqu’à : 4.0.0 - size-xlAvant de basculer notre version vers Octane, j’aimerais prendre le temps de convertir nos Classes en Classes natives et nos composants en composants Glimmer. Il y aura un peu de douleur impliquée, mais cela vaut la peine. Le ember-native-class-codemod devrait atténuer une partie de cette douleur. Nous verrons jusqu’où cela nous mène.
Il y a beaucoup de considérations et de problèmes de flux de travail à garder à l’esprit. La seule chose que je veux souligner est que cela suivra le même flux que j’ai mentionné pour les modèles - corriger et tester 1 composant par PR.
Étape 4
La mise à jour Ember 3.26 → Ember 3.27 introduit douze dépréciations. Je propose de les diviser en trois parties. Nous ferons l’augmentation de version après que toutes les dépréciations auront été traitées.
Ember 3.26 → Ember 3.27 (partie 1 - Général)
-
Réouverture de la super classe de composant classique
- jusqu’à : 4.0.0 - -
Plugins de compilation de modèles basés sur des classes
- jusqu’à : 4.0.0 - -
Argument LinkTo @disabled-when
- jusqu’à : 4.0.0 - Je ne pense pas que nous utilisions aucun de ceux-ci, donc il n’y a rien à faire ici.
-
Déprécier
Route#disconnectOutlet - jusqu’à : 4.0.0 - size-sNous ne faisons cela qu’en un endroit. C’est le
build-category-route, et cela devrait être simple à corriger. -
Invocation d’assistants sans arguments et parenthèses dans des positions d’arguments nommés
- jusqu’à : 4.0.0 - size-sJe ne pense pas que nous fassions cela nulle part, mais je confirmerai quand le moment sera venu. Essentiellement, appeler un assistant sans lui passer d’arguments.
Même si nous utilisons quelque chose comme cela, nous n’aurions besoin que d’ajouter des parenthèses. Donc, cela
<SomeComponent @arg={{someHelper}} />devient
<SomeComponent @arg={{(someHelper)}} />notez les parenthèses autour de
someHelper -
Boucle d’exécution et accès par point aux calculés
- jusqu’à : 4.0.0 - size-mNous utilisons
.pour accéder aux fonctionscomputeddans notre addondecorators. Ils ressemblent à ceci, par exemple
discourse/app/assets/javascripts/discourse-common/addon/utils/decorators.js at b05fddaa7ce3968ffc70cd8d4bf290e15d06eb11 · discourse/discourse · GitHubNous avons aussi quelques cas isolés ici et là. Pour autant que je sache, corriger ceux-ci consiste principalement à corriger la façon dont nous les importons.
Donc,
computed.filterdevrait être importé comme ceci à la place.import { filter } from '@ember/object/computed';Notre version de l’addon fournisseur externe
buffered-proxyutilise.pour accéder aux fonctionscomputed; nous devrons le mettre à jour.Nous utilisons aussi
.pour accéder aux fonctionsrunen quelques endroits. Cela dit, la même correction s’applique. Nous devons mettre à jour la façon dont nous les importons. Je pense que les thèmes et plugins en particulier pourraient avoir pas mal d’endroits où nous faisons cela avecrun -
Déprécier le Global Ember
- jusqu’à : 4.0.0 - (#size ?)Emberne sera plus disponible dans le contexte global après 4.0. Il est difficile d’estimer la quantité de travail/impact ici sans un examen plus approfondi. Cela dit, je sais que @cvx a fait beaucoup de travail pour se débarrasser de ce modèle.
Ember 3.26 → Ember 3.27 (partie 2 - renderTemplate)
Cette partie se concentrera uniquement sur une dépréciation.
-
Déprécier
Route#renderTemplate - jusqu’à : 4.0.0 - size-lEn un mot, nous ne pouvons pas utiliser de sorties nommées dans Ember 4.0. Donc, cela ne fonctionnera pas.
{{outlet "thing"}}Nous utilisons
renderTemplateen presque 30 endroits dans le noyau seul. La mise à niveau elle-même semble assez simple. Nous pouvons utiliser{{#in-element}}et un élément HTML vide ordinaire comme placeholder pour ce que nous utilisions pour rendre dans les sorties nommées.
Ember 3.26 → Ember 3.27 (partie 3 - Composants intégrés hérités)
Cette partie se concentrera sur les composants intégrés hérités, et elle traitera quatre dépréciations.
- Importation des composants intégrés hérités - jusqu’à : 4.0.0
- Arguments hérités des composants intégrés - jusqu’à : 4.0.0
- Arguments d’attribut HTML hérités des composants intégrés - jusqu’à : 4.0.0
- Réouverture des composants intégrés hérités - jusqu’à : 4.0.0
Je n’ai pas ajouté de tailles à ceux-ci parce que… cela dépend vraiment. Laissez-moi expliquer.
Les composants intégrés hérités comme Checkbox, TextField, TextArea, et LinkComponent seront supprimés dans Ember 4.0. Nous les utilisons en assez d’endroits, et nous utilisons aussi certains modèles dépréciés sur eux.
Ember offre une voie de mise à niveau qui nous permet de continuer à les utiliser, mais nous devons les importer différemment. Cependant, ils ne recevront aucune mise à jour d’Ember et resteront figés. J’espère que nous pouvons nous en débarrasser tous ; cependant, cela pourrait être un peu complexe. Ce changement nécessitera plus de discussion quand le moment sera venu.
Étape 5
Ember 3.27 → Ember 3.28
C’est un size-s car c’est seulement une augmentation de version. 3.28 est la dernière version LTS dans le cycle de développement 3.x. Elle n’introduit aucune nouvelle dépréciation après 3.27, et c’est une bonne version pour nous arrêter pendant quelques semaines pendant que les choses se stabilisent.
La LTS 3.28 est supportée jusqu’en août 2022 (corrections de bugs et correctifs de sécurité)
Cette “pause” a quelques avantages.
- Elle nous donne plus de temps pour voir si des problèmes surgissent
- quand nous publions une version stable, elle devrait être sur 3.28
- elle nous donne le temps de faire toutes les annonces nécessaires concernant les thèmes et plugins auto-gérés
- elle nous donne le temps de nous assurer que la transition jQuery → pas de jQuery est aussi fluide que possible.
Étape 6
Après quelques semaines, nous pouvons enfin augmenter notre version vers Ember 4
Ember 3.28 → Ember 4.1
Nous pouvons maintenant désactiver l’intégration jQuery optionnelle en tant que dernière dépréciation du cycle 3.x.
Cette mise à jour introduit deux dépréciations mineures.
-
Déprécier Ember.assign - jusqu’à : 5.0.0 - size-sNous ne l’utilisons pas dans le noyau, mais nous devrons vérifier les thèmes/plugins. Dans tous les cas, c’est un simple renommage. -
Classe AutoLocation
- jusqu’à : 5.0.0 - size-sEn théorie, nous n’aurions besoin que de changer
locationType: 'auto'enlocationType: 'history'dans notre fichier d’environnement Ember, et cela devrait simplement fonctionner.
Flux de travail
Comme je l’ai mentionné au début, nous ferons très attention avec ces mises à jour. Nous testerons/corrigerons/fixerons tous les plugins/thèmes officiels avec chaque mise à jour, et nous enverrons également des PR aux plugins/thèmes non officiels populaires.
L’objectif ici n’est pas de ralentir le développement ou de créer des maux de tête. Donc, les PRs seront strictement ciblées, avec un changement par PR et rien de trop grand.
Dans un monde idéal, tous les changements se produiraient en arrière-plan sans interrompre le travail des autres. C’est pourquoi nous prévoyons de garder les PRs courtes et simples. Aussi, nous n’aimons pas trop les modèles mixtes. Donc, nous ne voulons pas rester bloqué dans un état intermédiaire sur une base par fichier. Un composant est soit classique soit Glimmer, et un modèle utilise soit des accolades soit des chevrons, rien entre les deux.
J’espère que cette feuille de route était claire. Comme je l’ai mentionné au début, c’est juste un aperçu général de haut niveau. Si quelque chose est flou, incorrect, ou ne vous convient pas, veuillez nous le faire savoir.
) ?
