Di fronte alla vostra prima applicazione con Typescript, vi sarete certamente chiesti quale sia il modo migliore per dare ad essa il primo avvio. Può sembrare una domanda banale ma, essa cela delle considerazioni che dovrebbero essere tenute nella dovuta attenzione. Prima di tutto, è certamente vero che del codice Javascript è anche del codice Typescript perfettamente valido ma, se ci lasciamo prendere la mano e iniziamo a scrivere così come eravamo abituati in precedenza rischiamo di perdere i benefici che Typescript può regalarci.

Primo fra tutti, sicuramente il fatto che Typescript accentua fortemente le caratteristiche object oriented e di conseguenza ci dovremmo attendere di rappresentare l’applicazione – intendendo con essa una singola pagina al cui interno gira il codice che le da vita – con una sola classe, che detenga i riferimenti ai vari elementi e naturalmente lo stato. Un po’ come avviene in una applicazione asp.net, in cui una sigola pagina è rappresentata dal suo “codebehind”.

Per avviare una applicazione del genere dovremmo di conseguenza creare al più presto l’istanza della classe e dare ad essa il controllo, lasciando che gestisca il ciclo di vita della pagina fino alla sua naturale conclusione. Per questo tipo di avvio sono abituato ad utilizzare un pattern ormai abbstanza consolidato. Creaimo una classe base per la pagina, in un namespace comune che i usialmente chiamo “sys”:

   1: module sys
   2: {
   3:     export class Page
   4:     {
   5:         public static run(page: Page): void
   6:         {
   7:             $(() => page.onLoad());
   8:         }
   9:  
  10:         public onLoad(): void { }
  11:     }
  12: }

Come di può vedere , la classe consta di un metodo statico “run” e di un metodo virtual “onLoad”. Attenzione che in Typescript il concetto di virtuale non esiste ma in realtà qualunque metodo pubblico è anche virtual. Diamo per assodato che sia presente jQuery e all’interno del metodo run usiamo l’evento “readystatechanged” con la classica sintatti $(…) dove all’interno delle parentesi va indicata una funzione eseguita all’occorrenza di questo evento. A questo punto possiamo ereditare il codebehind concreto della pagina da sys.Page:

   1: class DefaultPage extends sys.Page
   2: {
   3:     constructor()
   4:     {
   5:         super();
   6:  
   7:         // inizializazione della pagina
   8:     }
   9:  
  10:     public onLoad(): void
  11:     {
  12:         // iniziamo qui il ciclo di vita
  13:     }
  14: }

In particolare nella classe viene riferinito il metodo onLoad che sarà chiamato automaticamente quando viene eseguito il “readystatechanged”. Potremmo così nel costruttore inizializzare i campi della classe, i valori di default, e così via mentre nell’onLoad potremmo cercare gli elementi della pagina, ed avviare eventuali operazioni di download da un servizio rest. L’avvio della pagina avviene per mezzo di una singola riga, posta usualmente in coda alla pagina o in un file ts:

   1: sys.Page.run(new DefaultPage());

La singola riga crea l’istanza della classe DefaultPage e poi vi da avvio con il metodo statico “run”. Niente di più semplice e pulito. Per estensione, se identificate all’interno della pagina diverse aree, a ciascuna delle quali risponda una classe Typescript che ne incapsuli il funzionamento, potete tranquillamente usare la stessa tecnica e ciascuna classe sarà avviata separatamente con il medesimo ciclo.

Di questo e di altro parleremo in occasione del Community LAB che si terrà il prossimo 28/2/2014 a Mestre. Se vi unite a me con il vostro PC sarà mia cura guidarvi nello sviluppo con questo semplice ma “liberatorio” linguaggio.

Iscrizioni e dettagli: http://www.xedotnet.org/Home/Meeting/20140228



Aggiungi Commento