Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ES (module) bundle per tree-shaking #54

Open
carmelone opened this issue Jan 7, 2021 · 2 comments
Open

ES (module) bundle per tree-shaking #54

carmelone opened this issue Jan 7, 2021 · 2 comments

Comments

@carmelone
Copy link

Ti ringrazio per il lavoro che hai fatto e che stai continuando a fare su questo progetto.

Stavo pensando che sarebbe bellissimo poter "staccare" l'enorme lista comuni e la lista province dal bundle finale (~ 412 KB).

Si potrebbe dare allo sviluppatore la possibilità di usare una propria. Ti dico questo perché in un progetto è già presente una lista di comuni e province uguale alla tua ma tutto il codice di calcolo/verifica è molto buggato.

E purtroppo quella lista non si può "staccare" dal resto quindi se voglio usare il tuo codice o lo copio a mano ogni volta che tu sistemi qualcosa oppure possiamo introdurre una build ES (module) con Rollup.

  • rollup.config.js:
export default {
    input: 'src/index.js',
    // input: 'src/codice-fiscale.js',
    output: {
        file: 'dist/codice-fiscale.es.js',
        format: 'es',
    }
};
  • src/index.js:
import { COMUNI } from "./lista-comuni";

export { COMUNI }

Mi sono fermato qui perché in Rollup per esportare ogni singola classe/funzione/costante essa deve essere esportata e prima volevo sentire te.

E ovviamente servirebbe anche un metodo tipo:

setListaComuni().

Cosa ne pensi?

Hai altre idee? Sto sbagliando?

Grazie ancora.

@lucavandro
Copy link
Owner

Ciao @carmelone . È un problema che mi sono posto anche io. Purtroppo per far funzionare la libreria c'è bisogno della lista dei comuni. Nel codice la lista dei comuni vive in un file separato, quindi basta sostituirla con la propria e fare una nuova build del progetto.

Capisco che il problema possa essere il tempo della richiesta, separando la richieste (1 per la libreria, 1 per la lista dei comuni) si aggiunge l'overhead della richiesta HTTP. Risultato: benefici in termini di performance nulli o trascurabili.

L'idea per risolvere la questione potrebbe risiedere nel trovare una struttura dati più efficiente per rappresentare l'intera lista dei comuni: sono aperto a suggerimenti.

@Belingheri
Copy link

Buon di,
Ho buttato giu' un idea di come potrebbe essere una soluzione che ne dici @lucavandro ?
Non ho potuto fare il branch nel tuo progetto quindi e' qui.
Per ora e' un abbozzo, viene chiamato solo nel costruttore anche se sarebbe piu' corretto fare una procedura static credo.
Vedi possibili problemi o dici che vale la pena di contunuare ?
Grazie.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants