Ciao amici! Sono io, Daniel.
Se mi conosci nella vita reale, probabilmente mi hai sentito blaterare a lungo su qualcosa che riguarda JavaScript. Il mio primo lavoro di programmazione professionale è stato quasi tutto in Vanilla JavaScript, quindi amo JS da molto tempo. A differenza di altri, trovo le sue stranezze ed eccentricità accattivanti. L'ereditarietà prototipale è un po' stravagante all'inizio, ma in realtà è piuttosto semplice per le esigenze quotidiane. Ho visto molte mode andare e venire (guardando Coffeescript). Detto questo, mi ci è voluto molto tempo per salire sul treno di Typescript. Ma ora che sono qui? Sono TUTTI IN.
I amore Typescript. Puoi stabilire contratti chiaramente comprensibili per le tue strutture di dati, funzioni e classi e farli rispettare in fase di compilazione. Ciò significa che se qualcuno usa in modo improprio qualcosa o se un contratto/interfaccia cambia, viene catturato. prima di e di danneggiare i tuoi utenti. È un codice che spiega come deve essere utilizzato. Cosa c'è di non bello in questo? Stavo già pensando a JS in questo modo, perché non aggiungere un livello per spiegare i miei pensieri? Questa soluzione è ideale per i team o per le funzioni trasversali, ma anche per il futuro (dopo che avrò dormito e dimenticato tutto).
Nel mio lavoro diurno usiamo TypescriptMa non è sempre stato così. Lavoro in un'applicazione che è mumble-mumble con molte generazioni di codice: dai tempi di React basato sulle classi con Redux+Thunks ai più moderni componenti funzionali basati su React Hooks. È come scavare tra i sedimenti rocciosi per scoprire i motivi storici. Tutto ciò che è nuovo è scritto in Typescript e questo è fantastico, ma non ci ha aiutato quando abbiamo dovuto scavare più a fondo nelle vecchie funzionalità (o *gasp* ripulire i debiti). Man mano che ci rendevamo conto della gioia di usare i nuovi componenti (e del dolore di usare quelli vecchi), volevo arrivarci più velocemente. Volevo vivere nel futuro, non nel passato.
Entrare Il comodissimo strumento di AirBnB, ts-migrate.
Volevo arrivare più velocemente. Volevo vivere nel futuro, non nel passato.
Questo strumento eccezionale analizza l'intera base di codice, convertendo tutti i file di .js(x) file a .ts(x).
Lo so, lo so, sembra una cosa sporca. Si imposta l'utilizzo del temuto qualsiasi tipo di dato, che è un no preferenziale. Nei punti in cui non riesce a determinare come i tipi debbano interagire, inserisce un commento che dice a Typescript di ignorare la riga successiva. Ancora una volta, lo so, lo so, questo non è meno sporco.
MA ascolta. Questi file JS si comportano già essenzialmente in questo modo. Non ci sono tipi, quindi ogni cosa è già un file qualsiasi.
Quindi, a prescindere dal problema, questo ha almeno due vantaggi strategici immediati:
- L'integrazione di nuovi componenti in quelli vecchi è ora sicura dal punto di vista del tipo. Prima di questa modifica, era come se si trattasse di un vecchio JS quando dovevamo inserirli in un vecchio codice.
- Questo significa che ora il nostro nuovo codice Typescript sta tirando su la qualità di questi vecchi file piuttosto che i vecchi file tirano giù l'intera base di codice.
- Ogni singolo punto che necessita di attenzione per essere davvero pronto per Typescript è ora contrassegnato da un commento o da un qualsiasi tipo di dato. Cerchiamo di ripulire ogni vecchio file che viene toccato, un file alla volta. Enumerare l'entità di un problema può richiedere molto tempo: con questo approccio, invece, è già fatto.
È un codice che spiega come deve essere usato. Cosa c'è di non bello in questo?
So che per alcuni di voi la sensazione di "sporcizia" rimarrà, ma vi dico che... la tua vita sarà migliore per questo. Il nostro è decisamente migliore. Siamo stati in grado di non accettare i file JS, forzando così ulteriormente l'adozione. Abbiamo un elenco chiaro dei nostri debiti JS rimanenti. E la pulizia dei vecchi file è diventata un'aggiunta facile al lavoro esistente, anziché un problema insormontabile.
I vantaggi positivi superano di gran lunga le preoccupazioni legate al disordine creato da un processo automatizzato. Questo non era chiaro prima che lo usassimo, ma è chiarissimo col senno di poi. Non è sempre così?
Abbraccia il futuro: ci vuole solo un po' di tempo e non te ne pentirai.
IT 
EN 
ES 
FR 
DE 
DE_AT
È un'ottima lettura per tutti gli sviluppatori JS che esitano a migrare a TypeScript. L'onestà dell'autore nel descrivere la sensazione di sporcizia della conversione automatizzata e il modo in cui questa migliora la qualità del codice è comprensibile e stimolante. Lo consiglio vivamente!