Language Integrated Query con JavaScript

Secondo alcuni studi americani, già dal gennaio del 2014, l'utilizzo di Internet - intesa come volume di traffico - richiesto da dispositivi mobili (smartphones e tablet) ha superato la quantità richiesta da computer desktop e ambienti business (servers e quant'altro). Questo dato deve far pensare: si tratta di uno dei traguardi più significativi da quando la rete globale è entrata nella nostra quotidianità.

Una persona media fruisce la rete in maniera del tutto nuova, con una frequenza differente, durante tutto l'arco della giornata e non soltanto nelle ore lavorative. Internet ha raggiunto persone di ogni età, cultura e ceto sociale.

E' questo ha portato - e porterà sempre di più in futuro - alla necessità di realizzare strumenti più accessibili, che permettano la fruizione delle informazioni in maniera semplificata ed intuitiva. Questo, cercando di raggiungere più terminali, e quindi più persone possibili.

E' così che - da oltre quattro anni (dal lontano 2010) - tecnologie fortemente orientate al "client-side" sono diventate parte della mia vita di sviluppatore. HTML5 (nelle sue varie draft"), CSS3 e sopratutto JavaScript sono il pane quotidiano con cui è necessario confrontarsi per ottenere risultati efficaci.

Framework client side come EmberJs, KnockoutJs, ma sopratutto AngularJs (senza dubbio con maggiore potenzialità - IMHO) hanno monopolizzato lo sviluppo del "Presentation Layer", cercando di fornire una "struttura organizzata" ad un linguaggio come JS, che strutturato non è.

Ma questi framework - da soli - non sono sufficienti per coprire tutte le peculiarità di uno sviluppo orientato al client. Specialmente per uno sviluppatore come me - che viene dal mondo server - la mancanza di "facilities" di un framework robusto e completo come .NET, si sentono...eccome.

Tutto questo per dire cosa? Che ho voluto fare un esperimento, una prova, per capire se fosse possibile portare sul web uno dei miei "pezzi" preferiti di .NET. LINQ: "Language Integrated Query"...una lode a Microsoft e al suo ideatore!

E adesso mi direte: "Ma il porting di LINQ per JavaScript già esiste...". Verissimo...e in molte incarnazioni. Ma la mia premessa era quella di un esperimento, iniziato dalle fondamenta, che cerca di modellare un concetto come le lambda expressions, che in JavaScript, in un certo senso, esistono già dagli anni novanta.

E' così che qualche mese fa ho iniziato il mio progetto jslinq (che fantasia, eh? :) ). Sono partito con "where" e "select", per arrivare a "count": e alla fine mi sono trovato per le mani una piccola libreria che mi aiuta tantissimo ogni giorno.

Il passaggio su GitHub è stato d'obbligo, così come la condivisione del codice sorgente. Recentemente la pubblicazione su NPM (per metterlo a disposizione di Node.js) e Bower (il package manager più diffuso per lo sviluppo client-side).

Ammettiamo di avere una struttura dati in formato JSON (con ogni probabilità scaricata da un WebApi lato server): L'idea è quella di poter fare tutte le trasformazioni, filtri, ordinamenti ("magheggi", in termine tecnico) che si può fare con una lista analoga server-side con LINQ. Dopo aver referenziato jslinq nella vostra pagina web - o nel modulo di Node.js - è sufficiente "dare in pasto" il nostro array di dati al costruttore, in questo modo:

Da qui è tutto facile ed intuitivo: Con "where" possiamo applicare un filtro sui dati, simulando di fatto la lambda expression che avremmo fatto con LINQ con una semplice "function", il cui unico parametro è l'istanza di un singolo elemento presente nell'array di dati. Si applica la condizione di filtro - in questo caso imponiamo che la proprietà "name" del singolo elemento sia uguale a "two", e si ritorna il risultato dell'operazione di confronto come uscita della "function" stessa. Facile, no?

Il sistema di jslinq è implementato come "chainable" ("concatenabile") e segue il medesimo principio delle "fluent" e di jQuery, per intenderci (che oltretutto è il medesimo di LINQ). Conseguenza di ciò il risultato della funzione "where" è a sua volta un oggetto "jslinq" che deve essere elaborato per ottenere un dato valido: questa elaborazione del valore di uscita viene fatto con il metodo "toList", che emette solo gli elementi che sono stati precedentemente filtrati dalla clausola "where".

Ammettiamo di voler ragguppare i dati originali per Otterremo una nuova struttura delle informazioni che riporterà come "key" il campo (o i campi) che è stato selezionato per il "groupBy", il conteggio degli elementi contenuti in ciascun gruppo, e la lista degli elementi opportunamente classificati. Questo il risultato della "function" applicata poco sopra: Attualmente jslinq è alla versione 1.0.12 che personalmente considero stabile per un uso in ambiente di Produzione. Contiene più di una ventina di operatori, molti dei quali ricalcano il comportamento di LINQ ("count", "max", "min", "singleOrDefault", ecc...). Ma naturalmente le esigenze quotidiane hanno portato ad arricchire sempre di più la libreria di nuove funzionalità ("intersect", "substract", "remove", ecc...), che pur nella loro banalità, permettono di ridurre al massimo il codice JavaScript che è necessario scrivere per operare su array di elementi.

Quando ci si trova a lavorare rispettando alla lettera (o quasi) il principio di "Separation of Concerns", avendo accesso al workflow applicativo solo attraverso delle API che emetto dati JSON, si incorre spesso nella necessità di "raffinare" i dati sul client. Questo per alleggerire il server ed evitare di creare dei metodi API troppo complessi nel loro utilizzo, oppure costruire una moltitudine di differenti chiamate che fanno quasi la stessa cosa. E' questo il momento in cui jslinq può essere d'aiuto, delegando al client stesso parte di una elaborazione "minimale" che diminuisce la complessità del server, e pesa pochissimo sul client.

Bon...questo è quanto. Fateci un giro! ;)