C’è stata una discussione di qualcuno un po’ di tempo fa sullo sviluppo in un tema vs un plugin. La parte Rails di https://www.pfaffmanager.com/ sta iniziando ad essere abbastanza stabile, e quello che vorrei fare è spostare lo sviluppo della parte Rails in un componente del tema. Questo sta funzionando abbastanza bene, e le modifiche nei template e negli initializer nel componente del tema stanno sovrascrivendo il plugin come previsto. Ma, le modifiche a javascripts/discourse/components/server-item.js.es6 nel tema non stanno sovrascrivendo gli stessi file nel plugin.
Suppongo che potrei rimuovere completamente la parte Ember dal plugin e farla esistere solo nel tema, ma ciò richiederebbe un giorno di lavoro per spostare, testare e caricare tutti quei pezzi sul server. Potrei starmi perdendo qualcosa di stupido? Dovrei accettare e rimuovere completamente dal plugin le cose che vorrei nel componente del tema? Dovrei semplicemente tenere tutto nel plugin?
Avere lo stesso codice sia nel componente del tema che nel plugin mi sembra un po’ strano - secondo me sarebbe meglio decidere tra componente del tema/plugin, e poi fare il tutto. Sovrascrivere interi file non è qualcosa che facciamo noi stessi, e non è qualcosa che raccomandiamo. Per sovrascrivere il comportamento del core/plugin, il tuo componente del tema dovrebbe usare metodi come api.modifyClass.
Sospetto che la causa principale qui sia che i moduli ES6 dei plugin sono prefissati diversamente dai moduli core/tema. Eseguendo questo sul tuo sito, vedo che i moduli sono prefissati con plugin. Sospetto che se abilitassi il componente del tema, vedremmo un’altra voce, ma con un prefisso diverso.
Sono d’accordo in generale, tuttavia, ci sono alcuni casi limite:
Dove il volume delle modifiche al javascript supera di gran lunga le modifiche al back-end, nel qual caso i componenti tematici sono un ottimo modo per distribuire e testare rapidamente il codice.
Dove la maggior parte della funzionalità può essere fornita nel componente tematico di base, ma l’aggiunta di un plugin complementare può aggiungere funzionalità aggiuntive non possibili solo in Javascript. Impiego questa tecnica in Topic List Previews, dove il componente fa il 90% di ciò che è in grado di fare l’add-on, ma se aggiungi anche il plugin, ottieni alcune funzionalità aggiuntive interessanti.
Detto questo, impacchettare tutto in un plugin ha senso poiché c’è meno confusione sulla configurazione e installazione e tutto è sempre tenuto in passo.
Ma anche nello scenario plugin+tema, non duplicerei il codice Ember sia nel plugin che nel tema. Quindi dovrei estrarre almeno la maggior parte dei template, degli initializer, dei componenti, dal plugin e averli solo nel componente tema.
Dato che sarò l’unico a confondermi sulla configurazione, non è un grosso problema. Mi piace molto l’idea di poter testare alcune nuove cose front-end sul sito live passando alla versione beta del tema.
L’altro problema che vedo riguarda l’esecuzione dei test qunit. (Faccio finta di poter capire come aggiungerne, il che è un altro problema a sé stante; penso che il mio problema sia che non so come inizializzare i test con i dati per visualizzare le cose…). Penso che se avrò dei test qunit nel mio plugin, questi verranno eseguiti quando effettuerò il push su GitHub (perché sono abbastanza sicuro di aver visto fallire i miei test non funzionanti).
Posso ottenere un componente tematico che faccia lo stesso?
Tecnicamente dovrebbe essere possibile, ma non credo che abbiamo ancora flussi di lavoro GitHub actions pronti all’uso per i temi. Il testing dei temi sta subendo una revisione in questo momento (per la transizione a ember-cli), ma dopo, forse saremo in grado di aggiungere alcuni modelli di flusso di lavoro per il testing dei temi a GitHub - discourse/.github
Scenario: Voglio sovrascrivere un template distribuito in un plugin. Ma voglio sovrascriverlo in modo controllato dal codice.
Quindi ho provato a distribuire il nuovo template in un componente del tema. Lo stesso file esiste in un plugin (ma è diverso).
Questo sembra funzionare sulla mia installazione cloud di sviluppo, ma non su un’installazione di produzione standard.
Quindi è giusto dire che non si può prevedere se questo avrà successo o meno con i template? Cioè, la pipeline degli asset è tale che non si può prevedere quale ‘template’ avrà la precedenza, poiché non esiste una precedenza predefinita o prevedibile?
Ho lavorato con una strana supposizione che ci fosse una gerarchia, qualcosa del tipo:
core
plugin
componente del tema
modifiche al sito locale
E se avessi inserito un “file” con lo stesso percorso e nome in un livello successivo di quella gerarchia, avrebbe sovrascritto qualsiasi definizione “precedente”.
Ma la mia supposizione probabilmente non è sicura?
L’unica soluzione “pacchettizzata” (escludendo le modifiche al sito locale) è quindi quella di fare un fork del plugin e apportare le modifiche direttamente al suo interno?
Questo in un certo senso sarebbe un peccato, poiché aumenterebbe lo sforzo di manutenzione per le personalizzazioni, dovendo unire periodicamente le modifiche al repository principale del plugin…
Il modo migliore sarebbe aggiornare il plugin esistente e fornirgli un plugin outlet e/o un’API di personalizzazione che il componente del tema possa utilizzare.
Il mio commento sopra riguardava specificamente la sovrascrittura di interi file JS (cioè moduli es6). Ciò non è possibile. La pipeline degli asset antepone automaticamente i moduli plugin/tema con il nome/ID del plugin/tema, quindi è impossibile creare un conflitto con il core.
Per i template, sappiamo che le persone (inclusi noi, in alcune situazioni) li sovrascrivono, quindi è probabile che manterremo funzionante quel sistema. Ma per favore ricorda che è un hack. Se il componente/controller originale cambia il suo comportamento, il tuo template sovrascritto probabilmente causerà l’interruzione del sito.
In generale penso che la gerarchia che hai menzionato (core, plugin, tema) dovrebbe essere vera, quindi se stai vedendo qualcosa di diverso, per favore condividi i dettagli dei percorsi dei file nel plugin e nel tema.
