Vogliamo aggiornare la versione di Ember utilizzata in Discourse.
Al momento siamo alla versione 3.15 e vorremmo arrivare alla 4.1.
Ci siamo prefissati l’obiettivo di completare questo lavoro entro la fine dell’anno. Si prega di notare che questo argomento è una roadmap e tutti i piani e le stime sono provvisori. Questo argomento non è inteso per ospitare discussioni significative su aggiornamenti o modifiche specifiche. Quindi, manteniamo la conversazione qui un po’ focalizzata. Le domande su come questi aggiornamenti influenzeranno il tuo sito/plugin/tema sono fuori argomento. Le modifiche pianificate sono al 100% sul front-end (app Ember).
Saremo estremamente attenti alle modifiche che introduciamo. Tutti i plugin/temi ufficiali verranno aggiornati (incluso qualsiasi lavoro personalizzato che CDCK abbia svolto per i suoi clienti). Invieremo anche PR per aggiornare tutti i plugin/temi non ufficiali popolari.
Nessun problema se hai un plugin/tema personalizzato che hai creato per il tuo sito. Aggiungeremo avvisi di deprecazione e creeremo gli annunci necessari in modo tempestivo per darti abbastanza tempo per apportare le modifiche richieste. Cercheremo anche di guidarti attraverso queste modifiche se necessario.
Iniziamo con gli obiettivi. Ovviamente vogliamo arrivare alla versione più alta disponibile, ma dobbiamo fissare obiettivi intermedi tra ora e la nostra destinazione finale.
Pianeggiamo di fare aggiornamenti incrementali. Invece di un grande aggiornamento alla 4.1, divideremo questo lavoro in sei fasi. Ogni fase si concentra su un aggiornamento di Ember.
| Fase | Dimensione | Aggiornamenti |
|---|---|---|
| 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 (Parte 1 - Generale) Ember 3.25 → Ember 3.26 (Parte 2 - Template) Ember 3.25 → Ember 3.26 (Parte 3 - jQuery) Ember 3.25 → Ember 3.26 (Parte 4 - Lavori preparatori Octane) Ember 3.25 → Ember 3.26 (Parte 5 - Octane) |
| 4 | size-l | Ember 3.26 → Ember 3.27 (Parte 1 - Generale) Ember 3.26 → Ember 3.27 (Parte 2 - RenderTemplate) Ember 3.26 → Ember 3.27 (Parte 3 - Componenti built-in legacy) |
| 5 | size-s | Ember 3.27 → Ember 3.28 |
| 6 | size-s | Ember 3.28 → Ember 4.1 |
La scelta di quelle versioni specifiche si basa interamente sulle deprecazioni e sulla quantità di lavoro che introducono - e sul rischio implicito.
Quindi, analizziamole più nel dettaglio per maggiore chiarezza.
Deprecazioni per aggiornamento
Fase 1 (size-l)
Ember 3.15 → Ember 3.16
Questo aggiornamento introduce solo una deprecazione.
-
Utilizzare il resolver di ember-CLI invece del resolver globale legacy
- fino a: 4.0.0 - size-lDiscourse ha il proprio resolver personalizzato che attualmente estende
Ember.DefaultResolver.La correzione consigliata è eliminare qualsiasi resolver personalizzato e utilizzare il resolver di Ember-CLI. È più facile a dirsi che a farsi perché abbiamo una buona quantità di logica personalizzata per gestire plugin e temi.
Un compromesso che funziona è estendere il resolver di Ember-CLI invece di estendere
Ember.DefaultResolver.
Fase 2 (size-m)
Ember 3.16 → Ember 3.25
Questo aggiornamento introduce otto deprecazioni.
-
@ember/string#loce{{loc}} fino a: 4.0.0 - 
-
Senza “for” - deprecazione integrata di Ember
fino a: 4.0.0 - -
Senza “since” - deprecazione integrata di Ember
fino a: 4.0.0 - -
tryInvoke da @ember/utils
fino a: 4.0.0 - -
API di distruzione Meta
- fino a: 3.25.0 - Non utilizziamo nessuno di questi, quindi non c’è nulla da fare qui.
-
Utilizzare getter Ember e verificare esplicitamente l’undefined - fino a: 4.0.0 - size-sQuesta è una deprecazione semplice. Dobbiamo solo rimuoveregetWithDefaultdalla nostra codebase e ci sono solo pochi punti in cui lo utilizziamo. -
Estensioni del prototipo String - fino a: 4.0.0 - size-mAnche questo è uno scambio semplice e a basso rischio, ma utilizziamo il prototipo stringa esteso di Ember in diversi punti. Da un controllo rapido, penso che ci siano circa < 100 punti in cui lo facciamo tra core e plugin/temi.Una volta aggiornati, dovremmo anche impedire a Ember di estendere quel prototipo con qualcosa del genere.EXTEND_PROTOTYPES: { String: false }nel nostro file environment.
-
Importazione dihtmlSafeeisHTMLSafeda @ember/string - fino a: 4.0.0 - size-mC’è molta sovrapposizione tra questo e il punto #7 in questo aggiornamento, e dovrebbe essere diretto e a basso rischio.
Fase 3 (size-xl)
L’aggiornamento da 3.25 a 3.26 è piuttosto complesso. È qui che facciamo la maggior parte del “recupero”. Ci sono sedici deprecazioni in totale. Divideremo questo aggiornamento in cinque parti - dove faremo un aumento di versione solo dopo che tutte le deprecazioni sono state gestite.
Ember 3.25 → Ember 3.26 (Parte 1 - Generale)
Questa parte si occupa di nove deprecazioni relativamente più facili da gestire.
-
Osservatori di Array
- fino a: 4.0.0 - -
Capacità del Manager dei Componenti
- fino a: 4.0.0 - -
Capacità del Manager dei Modifier
- fino a: 4.0.0 - -
Funzionalità opzionale: application-template-wrapper
- fino a: 4.0.0 - -
classBinding e classNameBindings come argomenti nei template
- fino a: 4.0.0 - Nulla da fare qui; non utilizziamo quelli.
-
Metodi di transizione di route e controller
- fino a: 5.0.0 - size-mQuesta deprecazione rimuove un paio di metodi da
routesecontrollers. Potrebbe sembrare una modifica complessa, ma dovrebbe essere diretta. Dovremmo solo iniettare ilRoutercome servizio e chiamarli da lì - quando necessario. La parte difficile è che li utilizziamo in molti punti e tutti devono essere aggiornati. -
Politica di supporto del browser - fino a: 4.0.0 - size-s~~Questo dovrebbe essere un cambiamento relativamente semplice. Ember non supporterà IE11 a partire da 4.0. La cosa positiva è che non lo supportiamo da molto tempo comunque. L’unica cosa che dobbiamo cambiare è smettere di traspilare per IE11 in produzione.
discourse/app/assets/javascripts/discourse/config/targets.js at 1472e47aae5bfdfb6fd9abfe89beb186c751f514 · discourse/discourse · GitHubHo fatto alcuni test basici e questo cambiamento ci farà risparmiare circa 60kb (gzip) o ~6% dei nostri bundle principali e vendor nelle installazioni di Ember-CLI in produzione. -
{{hasBlock}} e {{hasBlockParams}} - fino a: 4.0.0 - size-sLi utilizziamo in un paio di punti. Questo è un semplice rinominamento a basso rischio. -
Helper{{with}} - fino a: 4.0.0 - size-sLo utilizziamo raramente, ma ha comunque bisogno di essere corretto. Dobbiamo solo sostituirli e utilizzare{{let}}o una combinazione di{{if}}/{{else}}
Ember 3.25 → Ember 3.26 (Parte 2 - Template)
Questa parte si concentrerà principalmente sulle deprecazioni che coinvolgono i template .hbs. Ci sono tre deprecazioni su cui dobbiamo concentrarci qui.
-
Ricerca di fallback delle proprietà
- fino a: 4.0.0 - size-lA partire da Ember 4.0, questo non funzionerà più.
Ciao, {{name}}!Se abbiamo una proprietà in un template, dobbiamo cercarla con un
thisprefisso cosìCiao, {{this.name}}!Dovremo farlo con tutti i nostri template. Ci sono modi per ridurre il dolore qui. Possiamo provare il ember-no-implicit-this-codemod e vedere quanto ci porta avanti.
Sono a favore di limitare le modifiche a 1 file per PR. Questo facilita la revisione - e il rollback se qualcosa va storto.
-
Accesso agli argomenti nominati tramite {{attrs}}
- fino a: 4.0.0 size-xlL’oggetto
{{attrs}}verrà rimosso in Ember 4.0. La modifica in sé è molto diretta e l’esempio di Ember è piuttosto bello.Prima:
{{attrs.foo}} {{this.attrs.foo.bar}} {{deeply (nested attrs.foobar.baz)}}Dopo:
{{@foo}} {{@foo.bar}} {{deeply (nested @foobar.baz)}}Dovremo farlo per tutti i nostri template. Possiamo combinare questa modifica con la conversione dei template nella sintassi a parentesi angolari. Sono un grande fan delle parentesi angolari perché sono molto più vicine alla sintassi standard dei web-component personalizzati.
Una cosa che potrebbe accelerare i nostri progressi qui è il ember-angle-brackets-codemod. Dovremo sperimentare con esso e vedere quanto ci porta avanti. Gestisce la deprecazione e ci dà una bella sintassi a parentesi angolari.
Simile al punto #1 in questa parte, sono anche a favore di correggere e testare un template per PR.
-
Argomenti posizionali
<LinkTo> - fino a: 4.0.0 - size-mAnche questa è una deprecazione che mira a ridurre la confusione. Ci sono alcuni punti in cui utilizziamo argomenti posizionali su link-to. Possiamo correggerli così
Prima:
{{link-to "Chi siamo" "about"}} {{#link-to "about"}}Chi siamo{{/link-to}} {{#link-to "post" @post}}Leggi {{@post.title}}...{{/link-to}}Dopo (con parentesi angolari):
<LinkTo @route="about">Chi siamo</LinkTo> <LinkTo @route="about">Chi siamo</LinkTo> <LinkTo @route="post" @model={{@post}}>Leggi {{@post.title}}...</LinkTo>
Ember 3.25 → Ember 3.26 (Parte 3 - jQuery)
Non c’è molto da dire su questo che tu non sappia già. Le nuove app Ember non utilizzano jQuery e verrà rimosso in Ember 4.0.
In questa parte, ci concentreremo su una deprecazione.
-
Funzionalità opzionale: jquery-integration
- fino a: 4.0.0 - size-xlNegli ultimi anni, abbiamo fatto enormi progressi nella riduzione dell’utilizzo di jQuery. Ci sono ancora punti in cui ne abbiamo bisogno, in particolare nel composer e come dipendenza per alcune librerie vendor che utilizziamo. Non voglio entrare nei dettagli di questa modifica qui. Per fare breve, dovremmo allontanarci dall’utilizzo di jQuery.
Tuttavia, vorrei sottolineare che anche se eliminiamo jQuery OVUNQUE, dovremmo comunque mantenere questa opzione impostata su true fino a quando non saremo pronti per Ember 4.0. Abbiamo bisogno di un piano per facilitare la transizione per i siti con temi/plugin personalizzati che non controlliamo. In altre parole, facciamo il lavoro ma conviviamo con l’avviso di deprecazione sul disattivamento dell’opzione.
Ember 3.25 → Ember 3.26 (Parte 4 - Lavori preparatori Octane)
In questa parte, dovremmo concentrarci sul preparare i nostri file per Octane. Gestiremo due deprecazioni.
-
Funzionalità opzionale: template-only-glimmer-components
- fino a: 4.0.0 - size-mQuesto è un cambiamento semplice in teoria, ma c’è un lavoro implicito che dobbiamo fare prima di poter attivare quell’opzione.
Dobbiamo assicurarci che i nostri attuali componenti solo-template funzionino con la semantica glimmer. Ho fatto alcuni test e i nostri test hanno avuto problemi con quell’opzione attivata. Ecco un esempio di elenco di alcuni componenti solo-template che abbiamo nel core
- 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.hbsDovremo anche controllare i nostri template Admin/tema/plugin e assicurarci che tutto funzioni prima di rilasciare quell’opzione.
A prima vista, non sono esattamente sicuro di come i nostri template
.hbrgrezzi si inseriscano in questo. Tuttavia, @david ha lavorato su liste di topic basate su glimmer. Quindi, forse possiamo fare a meno dei template grezzi del tutto. -
Iniezioni implicite
- fino a: 4.0.0 size-xlUtilizziamo iniezioni implicite ovunque. Lo facciamo in un initializer così
discourse/app/assets/javascripts/discourse/app/pre-initializers/inject-discourse-objects.js at ac79c5efc61d259705eeb487ca21d0ec3c535807 · discourse/discourse · GitHubEmber si sta allontanando dalle iniezioni implicite. La via preferita è convertire il maggior numero possibile dei nostri oggetti in servizi e iniettarli esplicitamente dove sono necessari. Ovviamente, potrebbero esserci alcune cose in cui un servizio non è ideale. In quei casi, possiamo cercare quegli oggetti direttamente quando sono necessari così
getOwner(this).lookup('thing:main')Un’altra opzione che abbiamo (a seconda delle implicazioni sulle prestazioni) è avvolgere le Classi Ember con la nostra Classe Discourse. Utilizzeremmo poi la nostra Classe in tutta l’app. Qualcosa come facciamo con la
Classe GlimmerComponent
discourse/app/assets/javascripts/discourse/app/components/glimmer.js at fa0c796baf9a7f64a3b27823b1aa4b370a74c3eb · discourse/discourse · GitHub. Questo renderebbe questo compito un size-l o anche size-mIn ogni caso, questo cambiamento richiederà qualche riflessione.
Ember 3.25 → Ember 3.26 (Parte 5 - Octane)
Questo è lo sforzo finale dell’aggiornamento 3.25 → Ember 3.26. Avremo solo una deprecazione rimasta a questo punto, ma è una grossa.
-
Edizione: Classic
- fino a: 4.0.0 - size-xlPrima di poter attivare la nostra versione su Octane, vorrei dedicare tempo a convertire le nostre Classi in Classi native e i nostri componenti in componenti Glimmer. Ci sarà un po’ di dolore coinvolto, ma ne vale la pena. Il ember-native-class-codemod dovrebbe alleviare parte di quel dolore. Dovremo vedere quanto ci porta avanti.
Ci sono molte considerazioni e problemi di flusso di lavoro da tenere a mente. L’unica cosa che voglio sottolineare è che seguirà lo stesso flusso che ho menzionato per i template - correggere e testare 1 componente per PR.
Fase 4
L’aggiornamento Ember 3.26 → Ember 3.27 introduce dodici deprecazioni. Propongo di dividerle in tre parti. Faremo l’aumento di versione dopo che tutte le deprecazioni sono state gestite.
Ember 3.26 → Ember 3.27 (parte 1 - Generale)
-
Riapertura della Super Classe del Componente Classic
- fino a: 4.0.0 - -
Plugin di compilazione del template basati su Classe
- fino a: 4.0.0 - -
Argomento LinkTo @disabled-when
- fino a: 4.0.0 - Non penso che utilizziamo nessuno di questi, quindi non c’è nulla da fare qui.
-
Deprecazione di
Route#disconnectOutlet - fino a: 4.0.0 - size-sLo facciamo solo in un punto. È la
build-category-routee dovrebbe essere diretto da correggere. -
Invocazione di Helper senza Argomenti e Parentesi in Posizioni di Argomento Nominati
- fino a: 4.0.0 - size-sNon penso che lo facciamo da nessuna parte, ma lo confermerò quando arriverà il momento. Essenzialmente, chiamare un helper senza passargli alcun argomento.
Anche se utilizzassimo qualcosa del genere, dovremmo solo aggiungere parentesi. Quindi, questo
<SomeComponent @arg={{someHelper}} />diventa
<SomeComponent @arg={{(someHelper)}} />nota le parentesi intorno a
someHelper -
Accesso con punto a run loop e computed
- fino a: 4.0.0 - size-mUtilizziamo
.per accedere alle funzionicomputednel nostro addondecorators. Sembrano così, per esempio
discourse/app/assets/javascripts/discourse-common/addon/utils/decorators.js at b05fddaa7ce3968ffc70cd8d4bf290e15d06eb11 · discourse/discourse · GitHubAbbiamo anche un caso isolato qua e là. Per quanto posso vedere, correggere quelli riguarda principalmente il correggere come li importiamo.
Quindi,
computed.filterdovrebbe essere importato così invece.import { filter } from '@ember/object/computed';La nostra versione dell’addon vendor esterno
buffered-proxyutilizza.per accedere alle funzionicomputed; dovremmo aggiornarlo.Utilizziamo anche
.per accedere alle funzionirunin alcuni punti. Detto questo, si applica la stessa correzione. Dobbiamo aggiornare il modo in cui le importiamo. Penso che temi e plugin in particolare potrebbero avere diversi punti in cui lo facciamo conrun. -
Deprecazione del Globale Ember
- fino a: 4.0.0 - (#size ?)Embernon sarà disponibile nel contesto globale dopo 4.0. È difficile stimare la quantità di lavoro/impatto qui senza un esame più approfondito. Detto questo, so che @cvx ha fatto un sacco di lavoro per eliminare questo pattern.
Ember 3.26 → Ember 3.27 (parte 2 - renderTemplate)
Questa parte si concentrerà solo su una deprecazione.
-
Deprecazione di
Route#renderTemplate - fino a: 4.0.0 - size-lIn sintesi, non possiamo utilizzare outlet nominati in Ember 4.0. Quindi, questo non funzionerà.
{{outlet "thing"}}Utilizziamo
renderTemplatein quasi 30 punti solo nel core. L’aggiornamento in sé sembra piuttosto diretto. Possiamo usare{{#in-element}}e un elemento HTML vuoto come segnaposto per quello che usavamo per rendere negli outlet nominati.
Ember 3.26 → Ember 3.27 (parte 3 - Componenti built-in legacy)
Questa parte si concentrerà sui componenti built-in legacy e gestirà quattro deprecazioni.
- Importazione di Componenti Built-in Legacy - fino a: 4.0.0
- Argomenti Legacy dei Componenti Built-in - fino a: 4.0.0
- Argomenti Attributo HTML Legacy dei Componenti Built-in - fino a: 4.0.0
- Riapertura di Componenti Built-in Legacy - fino a: 4.0.0
Non ho aggiunto dimensioni a questi perché… dipende davvero. Lasciate che spieghi.
I componenti built-in legacy come Checkbox, TextField, TextArea e LinkComponent verranno rimossi in Ember 4.0. Li utilizziamo in diversi punti e utilizziamo anche alcuni pattern deprecati su di essi.
Ember offre un percorso di aggiornamento che ci permette di continuare a usarli, ma dobbiamo importarli diversamente. Tuttavia, non riceveranno aggiornamenti da Ember e rimarranno congelati. Spero che possiamo fare a meno di tutti loro; tuttavia, questo potrebbe essere un po’ complesso. Questo cambiamento richiederà più discussione quando arriverà il momento.
Fase 5
Ember 3.27 → Ember 3.28
Questo è un size-s poiché è solo un aumento di versione. 3.28 è l’ultimo rilascio LTS nel ciclo di sviluppo 3.x. Non introduce nuove deprecazioni dopo 3.27 ed è una buona versione su cui fermarci per alcune settimane mentre le cose si stabilizzano.
L’LTS 3.28 è supportato fino ad agosto 2022 (sia correzioni di bug che patch di sicurezza)
Questa “pausa” ha alcuni vantaggi.
- Ci dà più tempo per vedere se sorgono problemi
- quando rilasciamo una versione stabile, dovrebbe essere sulla 3.28
- ci dà tempo per fare qualsiasi annuncio necessario riguardo a temi e plugin mantenuti autonomamente
- ci dà tempo per assicurarci che la transizione jQuery → no jQuery sia il più fluida possibile.
Fase 6
Dopo alcune settimane, possiamo finalmente aumentare la nostra versione a Ember 4
Ember 3.28 → Ember 4.1
Possiamo ora disattivare l’integrazione jQuery opzionale come ultima deprecazione del ciclo 3.x.
Questo aggiornamento introduce due deprecazioni minori.
-
Deprecazione di Ember.assign - fino a: 5.0.0 - size-sNon lo utilizziamo nel core, ma dovremo controllare temi/plugin. In ogni caso, è un semplice rinominamento. -
Classe AutoLocation
- fino a: 5.0.0 - size-sIn teoria, dovremmo solo cambiare
locationType: 'auto'inlocationType: 'history'nel nostro file environment Ember e dovrebbe funzionare.
Flusso di lavoro
Come ho menzionato all’inizio, saremo molto attenti con questi aggiornamenti. Testeremo/correggeremo/fisseremo tutti i plugin/temi ufficiali con ogni aggiornamento e invieremo anche PR a plugin/temi non ufficiali popolari.
L’obiettivo qui non è rallentare lo sviluppo o creare mal di testa. Quindi, i PR dovrebbero essere strettamente delimitati, con un cambiamento per PR e nulla di troppo grande.
In un mondo ideale, tutti i cambiamenti accadrebbero in background senza interrompere il lavoro di qualcun altro. Questo è il motivo per cui pianeggiamo di mantenere i PR brevi e dolci. Inoltre, non siamo troppo fan di pattern misti. Quindi, non vogliamo rimanere bloccati in uno stato intermedio su base per file. Un componente è o classic o Glimmer, e un template utilizza o parentesi graffe o parentesi angolari, nulla in mezzo.
Spero che questa roadmap fosse chiara. Come ho menzionato all’inizio, questa è solo una panoramica generale di alto livello. Se qualcosa non è chiaro, errato o non ti convince, per favore faccelo sapere.
)?
