Quando si parla di dipendenze , entrambi i termini possono essere usati, a volte in modo (pericoloso) intercambiabile. React è un framework o una libreria? Che dire di Bootstrap o Lodash ? Entrambi sono " pacchetti " dopotutto, giusto?

Certo, ma sicuramente non hanno lo stesso impatto sulla tua app.

Biblioteche

Una biblioteca ("bibliothèque" in francese, ma la maggior parte dei francesi dice "librairie" che in realtà significa "libreria" in francese, ma corrisponde alla pronuncia inglese di "library") è un insieme di funzioni per scopi generali (come underscore.js ) o quelli specializzati (come moment.js ).

Chiami le funzioni di libreria ogni volta che ne hai bisogno, come se scegliessi strumenti in una cassetta degli attrezzi. Non richiedono alcuna modifica nella progettazione del software .

Chiamate proprietarie

Come dipendenza, tuttavia, ti richiedono di chiamare la loro API proprietaria, "bloccando" così il tuo codice con loro (o forse anche una loro versione ), in modo che una chiamata alla libreria dovrebbe assomigliare a questa:

Tale blocco aumenterà con il numero di chiamate che stai emettendo: più chiami la libreria, più il tuo codice dipenderà da essa (o da una sua versione):

Unico punto di dipendenza

Per limitare tale dipendenza, tuttavia, puoi nasconderla dietro un wrapper:

Un tale involucro può effettivamente servire a più di uno scopo. Oltre a ridurre il blocco a un singolo punto nella tua base di codice, ti consente di esporre la tua API ai chiamanti. Un tale adattamento della libreria includerà solo l'API che ha senso per la tua app, così come i tipi di I/O specifici non per la tua app, non per la libreria.

Tuttavia, parlando di implementazione, passo dopo passo, il tuo codice dipende ancora da quello della libreria.

API aziendale

Si spera, come diceva il defunto David J. Wheeler:

Tutti i problemi in informatica possono essere risolti da un altro livello di indiretto .

In effetti, puoi evitare tale dipendenza aggiungendo un'interfaccia :

• i chiamanti dipenderanno da quella dichiarazione API;
• l'adattatore dovrà implementarlo (si noti che ciò faciliterebbe anche il mocking delle librerie durante il test).

Quadri

I framework ("quadriciels" in francese ufficiale, ma tutti dicono "framework") sono diversi, in quanto forniscono un diverso tipo di servizio: si offrono di gestire le cose per te, invece di lasciarti decidere cosa fare.

Cedere il controllo

Per fare ciò, implementano la spina dorsale (il "frame") di un'applicazione e ti consentono di riempire gli spazi vuoti. Ma quegli spazi vuoti sono lasciati in luoghi definiti e hanno forme definite.

Ciò significa che:

• l'app inizia con il framework : devi consegnare il volante.
• poiché il framework guida l'app, non sei più tu a effettuare chiamate: invece, verrai richiamato dal framework quando appropriato.

Contratti

Ovviamente nulla ti impedisce di chiamare manualmente del tuo codice, una libreria di terze parti o anche qualche API del framework, ma a tuo rischio e pericolo . Questo potrebbe funzionare o meno come previsto. I framework hanno regole che dovresti seguire e, se le infrangi, il framework non potrebbe essere ritenuto responsabile di eventuali errori.

In genere un framework ti consentirà di scrivere componenti che si adatteranno ai loro contenitori attraverso l'implementazione di un contratto :

Il contenitore sarà quindi in grado di gestire il tuo codice come un pezzo software compatibile con il framework il cui ciclo di vita può essere gestito e ti richiamerà nei momenti rilevanti per eseguire un tipo di operazione o un altro.

Come puoi vedere, questa è una scelta molto più strutturale rispetto alle librerie per la progettazione della tua applicazione: tutti i tuoi componenti diventano specifici per quel framework. Non sarà portabile (cioè non compreso da un altro framework) né interoperabile (cioè un componente Angular difficilmente interagirà con un componente React).

Si potrebbe sostenere, tuttavia, che il modello dell'adattatore potrebbe essere utilizzato per limitare la dipendenza dal framework, proprio come abbiamo fatto per limitare la dipendenza dalle librerie:

Questo può sembrare utile... se la direzione della dipendenza fosse la stessa. Ma non lo è: gli adattatori delle librerie assumevano una forma richiesta dall'app, mentre qui gli adattatori dei componenti possono solo assumere la forma di ciò che il framework si aspetta. Di conseguenza, il componente app apparentemente "gratuito" può solo imitare il contratto iniziale (ciclo di vita, semantica, granularità).

All'interno dei framework, gli adattatori dei componenti sarebbero quindi una stratificazione non necessaria.

Librerie quadro

Le biblioteche possono anche essere conformi ai framework. Invece di fornire un'API, forniscono implementazioni di componenti per un determinato framework.

Man mano che i framework diventano popolari, sono diventate disponibili numerose librerie di framework. La maggior parte di essi riguarda i widget, tuttavia: ad esempio i componenti di Material Design sono stati portati da Android a Web Components , Angular , React , Vue e persino ai framework iOS .

Quadri standard

Chiunque può immaginare l'enorme costo del porting della stessa libreria (e delle sue versioni successive) su ciascuno di quei framework.

IBM ha escogitato una soluzione al riguardo : invece di eseguire il porting di Carbon Design System su ciascuno dei framework pubblicizzati passati, attuali e futuri, ha investito in un porting sul framework Web Component standard , che può essere utilizzato in qualsiasi contesto.

Quindi, non solo questo consente di utilizzare i loro componenti dai framework:

Ma gli stessi componenti possono essere utilizzati anche da una semplice app:

Conclusione

Framework e librerie sono opzioni di terze parti molto diverse:

• I framework ti forniscono blueprint dell'applicazione con servizi integrati ma applicano contratti predefiniti per chiamare il tuo codice. In quanto tali, implicano una forte dipendenza .
• le librerie non ti aiuteranno a progettare la tua applicazione, ma possono essere chiamate solo quando ne hai bisogno. Puoi ideare un design che limiti la dipendenza da loro.