Moduli "Standalone"

[AlessandroVecchi]

è possibile rendere disponibili i singoli moduli (es, il megamenu) come standalone, cioè funzionanti senza dover inserire l'intero js IWT e i relativi css?

[gunzip]

è possibile ma al momento è macchinoso: https://italia.github.io/ita-web-toolkit/docs/compatibilita.html

stiamo lavorando per rendere semplice la procedura.

[AlessandroVecchi]

Sarebbe utile anche separare le classi delegate al funzionamento degli script da quelle adibite alla formattazione. Non usando un pre-processore css significa che devo sovrascrivere una marea di classi con anche un conseguente aumento del peso dei file.

[gunzip]

non mi è chiaro, puoi elaborare ? al momento le classi delegate al funzionamento degli script sono quelle con prefisso js-

[AlessandroVecchi]

Sto integrando il megamenu del webkit in un progetto realizzato con bootstrap4. Non vorrei dover includere tutto il build.css, però se lo escludo non funziona più. In effetti mi sono espresso male, perché non è solo il js a far funzionare il megamenu ma il css stesso. Purtroppo le classi "Megamenu..." sono troppo integrate nel css ed estrapolarle singolarmente dal file di produzione è praticamente impossibile.

Ho provato ad utilizzare l'ambiente di sviluppo ma ho dei problemi.

[gunzip]

il miglior (e più semplice) modo per estrapolare i componenti è effettuare una custom build secondo quanto descritto qui: https://italia.github.io/ita-web-toolkit/docs/compatibilita.html

è sostanzialmente impossibile (e sconsigliata) qualsiasi tipo di procedura cut&paste su CSS e JS al fine di ottenere lo stesso risultato.

[AlessandroVecchi]

Se voglio ad esempio estrapolare solo il megamenu escludo tutti i pezzi tranne?

[gunzip]

a occhio dovrebbe bastare il seguente config:

   CONFIG.includes = [
           '(.*)base(.*)',
           '(.*)components(.*)',
           '(.*)utils(.*)',
           '(.*)megamenu(.*)',
         ]

ma è sicuramente migliorabile (es. non sono necessarie tutte le utils nè tutti i components): evitare di conoscere necessariamente a priori le dipendenze tra i componenti per poterli riutilizzare in qualsiasi contesto (es. assieme a B4 o qualsiasi altro framework) è ciò a cui si riferiva la frase "stiamo lavorando per rendere semplice la procedura": è stato pianificato un task che, una volta terminato, permetterà di includere un singolo componente (es. CONFIG.includes = ['megamenu']) in modo che si porti dietro tutte le dipendenze (CSS e JS) che gli occorrono, nella maniera più granulare possibile. a quel punto sarà possibile creare una GUI che faciliti la procedura di build.

[AlessandroVecchi]

Grazie, infatti non riuscivo a trovare la combinazione giusta perché mancando dei pezzi dava errore. Il css è sceso così da 131 a 85k. Sicuramente ci ancora un sacco di regole superflue, ma è già qualcosa.

IMHO il raggruppare più classi in regole comuni è utile per un unico progetto, però nell'ottica si un sistema modulabile, andrebbero definite tutte singolarmente, anche se ripetute.

[AlessandroVecchi]

Aggiungo: il definire tutte le regole con !important non mi sembra formalmente corretto, oltre al fatto che rende difficoltosa qualsiasi personalizzazione.

[gunzip]

l'utilizzo di !important laddove compare è voluto; forza gli aspetti grafici che i componenti devono avere e comunica allo sviluppatore l'intento della proprietà di non esser sovrascritta.

la personalizzazione deve avvenire agendo sulle variabili tramite una build personalizzata e non sovascrivendo le proprietà già impostate (altrimenti perde senso impostare tali proprietà nel CSS della baseline; tanto vale ometterle del tutto).

tra l'altro questo è il motivo per il quale lo stile grafico (skin / tema) degli elementi è separato (nel CSS) da quelle che sono proprietà "necessarie e inerenti". per dirne una, omettendo la classe Megamenu--default si ottiene un megamenu senza skin (colori, etc.), completamente personalizzabile senza sovascrivere alcunché (e senza effettuare custom build).

nei casi in cui il tk non rende possibile questo 'disaccoppiamento' (tra la skin e le proprietà "intoccabili"), va rivisto il CSS del tk, eliminando da esso le proprietà che è lecito personalizzare. è un caso che non dovrebbe presentarsi mai; dove si presenta è un errore e va corretto (nel tk).

per farla breve, la necessità di sovrascrivere le classi è indice del fatto che va rifattorizzato il codice del toolkit. in genere non dovrebbe esserci, in caso contrario proviamo a migliorarlo.

[AlessandroVecchi]

è cambiato qualcosa che ora vedo il build.css non più minimizzato?

[gunzip]

si, è stato escluso dai file versionati in git (nel branch master) poiché creava una serie di problematiche.

continuerai a trovare la versione minimizzata nel branch gh-pages: https://raw.githubusercontent.com/italia/ita-web-toolkit/gh-pages/build/build.css

[AlessandroVecchi]

Segnalo che dopo un anno non è ancora possibile estrapolare il codice dei singoli componenti di cui uno ha bisogno senza portarsi dietro un sacco di codice non voluto. Confido della prossima release...

[gunzip]

@AlessandroVecchi come avrai potuto notare dall'attività sui diversi repository, al momento l'effort è concentrato sullo sviluppo di https://github.com/italia/bootstrap-italia

[AlessandroVecchi]

A dire la verità no... ci guardo allora grazie

[AlessandroVecchi]

Ma scusa la domanda... all'inizio il progetto era stato fatto su bootstrap (3), poi si è preferito sviluppare un framework dedicato e adesso si è ritornati a bootstrap?

[gunzip]

esattamente. per questo tipo di discussioni il luogo più adatto è https://forum.italia.it :)