Apprezzo la flessibilità di avere a disposizione l’intera API dei componenti. Mi piace la sintassi dei componenti Glimmer nel complesso e capisco perché possa offrire vantaggi nel ridurre la complessità del codebase.
Tuttavia, per casi d’uso basilari (voglio aggiungere un pulsante e dargli un’icona), i vecchi metodi API erano oggettivamente più concisi e facili da capire (meno importazioni, meno operazioni, meno impronta dell’API esposta). C’è qualche motivo per cui i vecchi metodi API non potrebbero continuare a essere supportati? Immagino che se li utilizzaste come funzioni di convenienza ed eseguiste l’implementazione sottostante utilizzando il vostro nuovo componente Glimmer, il metodo API potrebbe anche eseguire il controllo di compatibilità delle versioni.
Ciò sarebbe molto meno dirompente per chiunque utilizzi questi metodi e creerebbe meno esplosione di codice di logica condizionale all’interno dell’ecosistema dei plugin.
La mia principale lamentela riguardo ai widget esistenti è la loro mancanza di documentazione. Questo post, che annuncia la loro rimozione, è uno dei documenti più chiari che abbia visto riguardo all’esistenza di questi particolari metodi e a come utilizzarli. Sono arrivato qui, infatti, cercando di capire come utilizzare la vecchia API.
Mi piace che i transformer siano registrati in un unico posto, tramite letterali di stringa. Penso che questo renda il lavoro di documentazione (e di sviluppo dei plugin) molto più semplice.
Con i widget, sembrano tutti essere registrati tramite il metodo createWidget, che poi chiama createWidgetFrom. Il problema che vedo in questo è che il _registro è una variabile globale a livello di file protetta da un’API, e l’API non consente alcuna iterazione. Se potessimo semplicemente ottenere una funzione di iterazione sul registro dei widget, potremmo scoprire in tempo reale i widget attualmente registrati. Dovrebbe essere documentato “esegui questa riga di javascript nella console del tuo browser per chiamare l’API ed elencare il registro”. Quindi potremmo ottenere un’utilità molto simile a quella che fornisce il registro dei transformer.
Un’altra cosa che aiuterebbe nello sviluppo dei plugin è vedere un attributo su qualsiasi elemento DOM radice renderizzato da un componente/widget che ti dica di quale componente/widget si tratta. Come “data-widget=foo”. Questa potrebbe essere una funzionalità di debug, o potrebbe essere semplicemente abilitata per impostazione predefinita. È OSS, quindi non è come se si stesse ottenendo sicurezza tramite l’oscurità.
Celebro il passaggio ai componenti Glimmer. Ma questo richiederà tempo, e nel frattempo ci sono molti widget con cui le persone devono lavorare. Quindi penso che migliorare la visibilità dei widget, come menzionato sopra, probabilmente renderà il periodo di transizione più facile per tutti.
Per quanto riguarda quei metodi API… Sembra che qualcuno si sia preso la briga di aggiungere commenti dettagliati all’API Javascript, ma non è mai stato generato un sito di documentazione per essa. Perché no?
Sarei felice di inviare una pull request per l’iterazione attraverso il registro dei widget, se ciò fosse accettabile.