Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Componenti, pattern e altre robette non semplicissime da gestire

Componenti, pattern e altre robette non semplicissime da gestire

Lavorare in un mondo di componenti è complesso. Tool, framework e design pattern l'hanno reso più accessibile, ma c'è ancora un passaggio che non è gestibile tramite codice: quand'è che un componente diventa un componente? Che valore semantico ha un pattern e come se ne riusa uno in uno scenario leggermente diverso, senza invalidare il concetto stesso di "pattern"?
Un talk che non si propone come soluzione, ma come guida per porre l'attenzione su un problema e capire cosa cerchiamo di fare quando ci sembra di martellare formine triangolari o quadrate in buchi evitendemente rotondi.

Marco Cedaro

March 15, 2019
Tweet

More Decks by Marco Cedaro

Other Decks in Programming

Transcript

  1. o… di come sono riuscito a dare un senso a

    Lost in Translation Componenti, pattern e altre robette non semplicissime da gestire
  2. “This movie is an hour and some odd minutes of

    my life I will never get back.” JoeB. Su Metacritic Disclaimer
  3. “Meaning is complex and often gets lost in translation. Everybody

    has their own mental model of things” Alla Kholmatova Lost in Translation
  4. Pattern Library “Pattern libraries are something I do a lot

    for client projects. […] It’s a technique I first saw […] Natalie Downe develop for client projects back in 2009” Anna Debenham
  5. Pattern Library “Pattern libraries are something I do a lot

    for client projects. […] It’s a technique I first saw […] Natalie Downe develop for client projects back in 2009” Anna Debenham
  6. Non è così semplice “When you actually try to apply

    a modular approach to your day to day work, it isn’t really that simple” Alla Kholmatova · June 2015
  7. Il problema Come organizziamo il nostro codice, per permetter il

    riutilizzo di pattern senza che siano troppo rigidi per il lavoro di tutti i giorni?
  8. Il problema Come gestiamo il nostro codice, per permetter il

    riutilizzo di pattern senza che siano troppo rigidi per il lavoro di tutti i giorni? 
 Come facciamo a riutilizzare i nostri pattern quando l'use case è un po' diverso?
  9. NON si tratta di un problema legato a un framework

    o a uno stack specifico: molti degli approcci possono essere applicati con BEM, style component o css modules indifferentemente
 
 Rigurda la modularità nella sua essenza
 
 Riguarda la responsabilità dei moduli
 
 Rigurda la manutenibilità del codice
 (tra le altre cose)
  10. //_content-actions.scss .content-actions { //[...] &__button { flex: 1 0 auto;

    padding: 1rem; line-height: 1.5; &:hover, &:focus { background: $grey-1; } &:active { background: $grey-2; } } }
  11. //_content-actions.scss .content-actions { //[...] &__button { flex: 1 0 auto;

    padding: 1rem; line-height: 1.5; &:hover, &:focus { background: $grey-1; } &:active { background: $grey-2; } } }
  12. //_content-actions.scss .content-actions { //[...] &__button { flex: 1 0 auto;

    padding: 1rem; line-height: 1.5; &:hover, &:focus { background: $grey-1; } &:active { background: $grey-2; } } } Quali effetti ha sul componente base?
  13. //_content-actions.scss .content-actions { //[...] &__button { flex: 1 0 auto;

    padding: 1rem; line-height: 1.5; &:hover, &:focus { background: $grey-1; } &:active { background: $grey-2; } } } Perché questo bottone è diverso da quelli nella pattern library?
  14. Cosa decisamente no 1. Gli stili originali possono essere sovrascritti

    in modi inaspettati. 2. Creiamo un numero indefinito di varianti dei pattern disponibili.
  15. - You're too tall.
 - Anybody ever tell you you

    may be too small? Modificatori ad hoc
  16. //_dialog.scss .dialog { //[...] &--wizard { width: 43.75rem; height: 35rem;

    } &--game-intent { width: 43.75rem; height: auto; } &--save-results { width: 23.75rem; height: auto; } } Quante varianti dobbiamo considerare?
  17. Cosa decisamente no 1. Le definizioni generiche dei componenti hanno

    "nozione" delle implementazioni specifiche 2. Le dimensioni del css aumentano a causa di codice inutilizzato 3. Non scala
  18. //_dialog.scss .dialog { //[...] &--prompt { display: block; overflow: hidden;

    max-width: map-get($dialog-prompt, max-width); height: auto; margin: map-get($dialog-prompt, margin); padding: 2rem 0 0; border-radius: 3px; } }
  19. //_dialog.scss .dialog { //[...] &--prompt { display: block; overflow: hidden;

    max-width: map-get($dialog-prompt, max-width); height: auto; margin: map-get($dialog-prompt, margin); padding: 2rem 0 0; border-radius: 3px; } } Il valore semantico dei pattern è molto diverso da quello dei modificatori ad hoc
  20. I pattern sono al centro della conversazione: non si tratta

    di casi speciali, ma di versioni predefinite dei componenti base. Cosa funziona
  21. I still wish I could sleep Decisamente da evitare: rende

    di fatto inutile il concetto di pattern library Un "code smell": si tratta di un hack e andrebbe trattato come tale Uno degli approcci fin qui migliori, seppur limitato Iniettare le classi Modificatori ad hoc Pattern specializzati
  22. //_dialog.scss .dialog { width: 100%; height: 100%; //[...] } //_game-intent.scss

    .game-intent { //[...] &__dialog { width: 43.75rem; height: auto; } }
  23. //_dialog.scss .dialog { width: 100%; height: 100%; //[...] } //_game-intent.scss

    .game-intent { //[...] &__dialog { width: 43.75rem; height: auto; } } Ogni component ha le sue responsabilità
  24. Questa pratica definisce responsabilità precise in modo chairo e crea

    la possibilità di avere implementazioni specifiche senza invalidare i pattern. Cosa funziona
  25. Cosa decisamente no Si creano una serie di wrapper che

    non sarebbero serviti altrimenti.
  26. Riduce la necessità di inventarsi nuove classi e sposta la

    conversazione sui rapporti tra gli elementi a livello di pattern library. Cosa funziona
  27. Cosa decisamente no 1. Le classi "posizionali" potrebbero diventare obsolete

    se non codificate appropriatamente nella pattern library 2. La flessibilità è limitata. 3. Classi semantiche?
  28. //_question-content-block.scss .question-content-block { //[...] &__icon-button { //[...] .icon { width:

    $content-block-icon-large-size; height: $content-block-icon-large-size; } }
  29. //_question-content-block.scss .question-content-block { //[...] &__icon-button { //[...] .icon { width:

    $content-block-icon-large-size; height: $content-block-icon-large-size; } }
  30. //_question-content-block.scss .question-content-block { //[...] &__icon-button { //[...] @include icon-size($content-block-icon-medium-size); }

    } //_icon.scss @mixin icon-size($size) { .icon { width: $size; height: $size; } } La responsabilità di "essere flessibile" è del componente stesso
  31. 1. Ogni componente base può essere flessibile quanto necessario. 2.

    Gli sviluppatori hanno controllo rispetto a quali "specializzazioni" offrire. Cosa funziona
  32. Cosa decisamente no 1. É una tecnica più complessa delle

    altre 2. Rischi di prendere una brutta piega 3. Come si può definire un componente "open" in una pattern library?
  33. The more you know who you are and what you

    want, the less you let things upset you