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.

Transcript

1. View Slide

2. Modular
   architecture
   

   View Slide

3. Modular architecture
   Classi e
   componenti
   

   View Slide

4. Modular architecture
   classi e
   Componenti
   e modificatori
   

   View Slide

5. Modular architecture
   classes and
   Componenti,
   modificatori
   e override
   

   View Slide

6. Modular architecture
   classi,
   modificatori
   and override
   Componenti, 

   pattern e altre robette
   non semplicissime da
   gestire
   

   View Slide

7. @cedmax
   Webmaster
   before it was cool
   

   Tech Lead 

   Condé Nast International
   

   View Slide

8. Componenti,
   pattern e altre
   robette non
   semplicissime da
   gestire
   

   View Slide

9. o… di come sono riuscito a dare un senso a Lost in Translation
   Componenti,
   pattern e altre
   robette non
   semplicissime da
   gestire
   

   View Slide

10. Basically
    Lost in Translation?
    

    View Slide

11. “This movie is an hour and some
    odd minutes of my life I will never
    get back.”
    JoeB. Su Metacritic
    Disclaimer
    

    View Slide

12. “Meaning is complex and often gets
    lost in translation. Everybody has
    their own mental model of things”
    Alla Kholmatova
    Lost in Translation
    

    View Slide

13. Modular design
    

    View Slide

14. 2013 - 2015
    

    View Slide

15. View Slide

16. Atomic design
    Brad Frost · Ottobre 2013
    

    View Slide

17. Web components
    annunciati nel Novembre 2011
    

    View Slide

18. 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
    

    View Slide

19. SLIDE MANCANTE* SULLE

    PATTERN LIBRARIES
    * di proposito, ve lo giuro
    

    View Slide

20. 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
    

    View Slide

21. ReactJS
    Rilascio: March 2013
    

    View Slide

22. Buongiorno, caffè?
    

    View Slide

23. Basically
    Inquadrare il problema
    

    View Slide

24. 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
    

    View Slide

25. Il problema
    

    View Slide

26. 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?
    

    View Slide

27. 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?
    

    View Slide

28. Wish I could sleep
    

    View Slide

29. 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)
    

    View Slide

30. Iniettare
    le classi
    I'll be in the bar for the rest of the week
    

    View Slide

31. View Slide

32. className="content-actions__button"
    iconId="close"
    />
    

    View Slide

33. className="content-actions__button"
    iconId="close"
    />
    

    View Slide

34. //_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;
    }
    }
    }
    

    View Slide

35. //_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;
    }
    }
    }
    

    View Slide

36. //_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?
    

    View Slide

37. //_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?
    

    View Slide

38. Si tratta del modo più flessibile di
    gestire eccezioni
    Cosa funziona
    

    View Slide

39. Cosa decisamente no
    1. Gli stili originali possono essere
    sovrascritti in modi inaspettati.
    2. Creiamo un numero indefinito di
    varianti dei pattern disponibili.
    

    View Slide

40. - You're too tall.

    - Anybody ever tell you you may be too small?
    Modificatori
    ad hoc
    

    View Slide

41. className="dialog--user-intent">
    
    
    

    View Slide

42. className="dialog--user-intent">
    
    
    

    View Slide

43. //_dialog.scss
    .dialog {
    //[...]
    &--user-intent {
    width: 43.75rem;
    height: auto;
    }
    }
    

    View Slide

44. //_dialog.scss
    .dialog {
    //[...]
    &--user-intent {
    width: 43.75rem;
    height: auto;
    }
    }
    

    View Slide

45. //_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?
    

    View Slide

46. Questa pratica permette una discreta
    flessibilità, offrendo controllo e
    mantendendo le varianti co-locate nel
    codice.
    Cosa funziona
    

    View Slide

47. 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
    

    View Slide

48. Pattern
    specializzati
    I'm special
    

    View Slide

49. className="dialog--prompt">
    
    
    

    View Slide

50. className="dialog--prompt">
    
    
    

    View Slide

51. //_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;
    }
    }
    

    View Slide

52. //_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
    

    View Slide

53. I pattern sono al centro della
    conversazione: non si tratta di casi
    speciali, ma di versioni predefinite dei
    componenti base.
    Cosa funziona
    

    View Slide

54. Cosa decisamente no
    1. Potrebbe portare ad astrarre troppo
    presto
    2. Copre un numero ridotto di eccezioni
    

    View Slide

55. type="prompt" />
    className="dialog--prompt">
    
    
    
    

    View Slide

56. 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
    

    View Slide

57. Basically
    Sono bloccato
    

    View Slide

58. Non è così semplice
    “It isn’t really that simple”
    Alla Kholmatova · June 2015
    

    View Slide

59. Il problema
    Come facciamo a riutilizzare i nostri
    pattern quando l'use case è un po'
    diverso?
    

    View Slide

60. Cosa sto
    cercando di
    risolvere?
    

    View Slide

61. Posizionamento
    nel parent
    component
    

    View Slide

62. className="game-intent__dialog">
    
    
    
    
    

    View Slide

63. className="game-intent__dialog">
    
    
    
    
    

    View Slide

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

    View Slide

65. //_dialog.scss
    .dialog {
    width: 100%;
    height: 100%;
    //[...]
    }
    //_game-intent.scss
    .game-intent {
    //[...]
    &__dialog {
    width: 43.75rem;
    height: auto;
    }
    }
    Ogni component ha le
    sue responsabilità
    

    View Slide

66. Questa pratica definisce
    responsabilità precise in modo chairo
    e crea la possibilità di avere
    implementazioni specifiche senza
    invalidare i pattern.
    Cosa funziona
    

    View Slide

67. className="custom-class">
    
    
    
    
    className="custom-class">
    
    
    

    View Slide

68. Cosa decisamente no
    Si creano una serie di wrapper che non
    sarebbero serviti altrimenti.
    

    View Slide

69. Posizionamento
    in relazione ad
    altri componenti
    

    View Slide

70. className="space-max inner-space-min">
    
    
    

    View Slide

71. className="space-max inner-space-min">
    
    
    

    View Slide

72. Riduce la necessità di inventarsi nuove
    classi e sposta la conversazione sui
    rapporti tra gli elementi a livello di
    pattern library.
    Cosa funziona
    

    View Slide

73. Cosa decisamente no
    1. Le classi "posizionali" potrebbero
    diventare obsolete se non codificate
    appropriatamente nella pattern library
    2. La flessibilità è limitata.
    3. Classi semantiche?
    

    View Slide

74. Componenti 

    "aperti"
    

    View Slide

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

    View Slide

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

    View Slide

77. //_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;
    }
    }
    

    View Slide

78. //_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;
    }
    }
    

    View Slide

79. //_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
    

    View Slide

80. 
    

    View Slide

81. 1. Ogni componente base può essere
    flessibile quanto necessario.
    2. Gli sviluppatori hanno controllo rispetto a
    quali "specializzazioni" offrire.
    Cosa funziona
    

    View Slide

82. 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?
    

    View Slide

83. Basically
    Does it get easier?
    

    View Slide

84. View Slide

85. The more you know who you are and what
    you want, the less you let things upset you
    

    View Slide

86. I just don't know what I'm supposed to be
    

    View Slide

87. “A common language is
    a first step towards
    communication across
    cultural boundaries. ”
    Ethan Zuckerman
    

    View Slide

88. Il problema
    Come facciamo a riutilizzare i nostri
    pattern quando l'use case è un po'
    diverso?
    

    View Slide

89. Il problema
    Come capire – ed espiremere – il
    significato di un'eccezione nei
    pattern?
    

    View Slide

90. Cercando ci capire cosa 

    si sta costruendo
    

    View Slide

91. Facendosi coinvolgere prima
    

    View Slide