Sviluppare plugin più velocemente separando il frontend in un componente del tema

Ho già chiesto in precedenza come configurare l’ambiente locale per codificare più velocemente durante la creazione di un plugin, e so che altri lo hanno fatto.

Ho utilizzato un nuovo flusso di lavoro che ha funzionato benissimo e ho pensato di condividerlo nel caso fosse utile ad altri. Non risolve tutto, ma rende le cose molto più piacevoli. Ecco i dettagli:

Innanzitutto, il mio problema precedente:

Per sviluppare un plugin, dovevo codificare da un’istanza locale di Discourse, e questo era molto lento perché: 1) qualsiasi modifica ai file richiedeva il ricaricamento della pagina, e il mio computer lo faceva molto lentamente quando eseguiva Discourse (circa 30 secondi per ogni ricaricamento di pagina), 2) il sito Discourse locale per lo sviluppo su cui testavo era molto lento (lento da navigare, ecc.), e 3) qualsiasi modifica al codice del plugin backend richiedeva l’arresto del server e il riavvio, e questo poteva richiedere alcuni minuti. Nel frattempo, la ventola del mio computer girava al massimo.

Di conseguenza, probabilmente impiegavo un’ora di codifica per fare ciò che normalmente avrei potuto codificare in circa 10 minuti con un flusso di lavoro fluido.


La mia soluzione

Al contrario dello sviluppo di un plugin, il flusso di lavoro per la codifica di un componente tema è fantastico, grazie alla Discourse theme CLI. (I miei passaggi per utilizzarla sono qui.) È veloce e fluido.

Perché codificare un tema o un componente tema è così più veloce e facile

Con lo strumento theme CLI, puoi codificare un tema localmente, ma “guardarlo” (cioè, eseguire il tema) su un sito live (sia il tuo sito effettivo, il tuo sito effettivo ma solo in modalità anteprima, o un sito live di test che hai configurato).

Quindi non è necessario eseguire Discourse stesso sulla tua macchina, e di conseguenza la mia macchina non rallenta come farebbe con un plugin. E ogni volta che apporti una modifica, basta aggiornare il sito live a cui sei collegato, e la modifica è lì.

Quindi, quello che ho capito: la maggior parte del tempo quando codifico un plugin, si tratta in realtà di roba frontend (file hbs, file javascript, ecc.). E solo una piccola parte viene spesa per la roba backend (configurazione di route, creazione di campi personalizzati, ecc.).

Invece di codificare tutto insieme, allora, sposta tutta la codifica frontend in un componente tema, per sfruttare il flusso di lavoro del componente tema.

Quando devo aggiornare la roba backend nel plugin, allora devo codificare di nuovo nel plugin, ma questo richiede solo circa il 20% del tempo (almeno nel mio sviluppo di plugin). Permettendomi ora di trascorrere l’80% del mio tempo con il flusso di lavoro del componente tema, molto più piacevole.

Quando arriva il momento di spostare tutto in produzione, posso:

  • Mantenere separati il componente tema e il plugin, e usarli entrambi sui siti Discourse pertinenti, oppure
  • Se è importante avere tutto il codice in un unico posto, spostare a quel punto il codice del componente tema nel plugin. Ammetto che può essere un po’ noioso, ma dovresti farlo solo quando sei pronto per l’aggiornamento per la produzione, godendoti nel frattempo il flusso di lavoro più veloce del componente tema.

Questo è tutto.

Non è rivoluzionario. Ma ha reso le cose molto migliori per qualcosa che mi ha ostacolato per un po’.

7 Mi Piace

Sì, è un buon approccio.

Ho usato questo approccio sulle anteprime dell’elenco degli argomenti per un po’ di tempo, spostando quante più funzionalità possibili nel TC e rendendolo autonomo. Funzionalità aggiuntive che richiedono modifiche all’API vanno quindi in un plugin e gli utenti sono incoraggiati a installarlo anche per sfruttarle (se possono).

L’unico problema con questo approccio è se stai condividendo il tuo codice e la modifica dell’API è una necessità, allora devi assicurarti che qualcuno installi entrambi i componenti. Dividerli in due non è il modo più conveniente per le persone di consumare il tuo lavoro, potenzialmente, quindi penso ancora che alla fine un’unica installazione di plugin sia ancora il miglior approccio per lavori open source di quella natura.

Se è solo per il tuo sito, allora certo, questo è fantastico!

3 Mi Piace

Sì, ci sono certamente situazioni in cui alla fine si desidera un’unica codebase. Il momento di illuminazione che ho avuto è stato che, anche se alla fine voglio un’unica codebase, potrei codificare tutte le cose front-end nel componente del tema, e poi, una volta che funziona, spostarlo nel plugin. Un po’ noioso, ma nel complesso molto meglio per me perché passo ancora la maggior parte del mio tempo a codificare nel flusso di lavoro del componente del tema.

2 Mi Piace