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.

3ca63d4e2f2be0ef47b841e63b564d18?s=128

Marco Cedaro

March 15, 2019
Tweet

Transcript

  1. None
  2. Modular architecture

  3. Modular architecture Classi e componenti

  4. Modular architecture classi e Componenti e modificatori

  5. Modular architecture classes and Componenti, modificatori e override

  6. Modular architecture classi, modificatori and override Componenti, 
 pattern e

    altre robette non semplicissime da gestire
  7. @cedmax Webmaster before it was cool 
 Tech Lead 


    Condé Nast International
  8. Componenti, pattern e altre robette non semplicissime da gestire

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

    Lost in Translation Componenti, pattern e altre robette non semplicissime da gestire
  10. Basically Lost in Translation?

  11. “This movie is an hour and some odd minutes of

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

    has their own mental model of things” Alla Kholmatova Lost in Translation
  13. Modular design

  14. 2013 - 2015

  15. None
  16. Atomic design Brad Frost · Ottobre 2013

  17. Web components annunciati nel Novembre 2011

  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
  19. SLIDE MANCANTE* SULLE
 PATTERN LIBRARIES * di proposito, ve lo

    giuro
  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
  21. ReactJS Rilascio: March 2013

  22. Buongiorno, caffè?

  23. Basically Inquadrare il problema

  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
  25. Il problema

  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?
  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?
  28. Wish I could sleep

  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)
  30. Iniettare le classi I'll be in the bar for the

    rest of the week
  31. None
  32. <IconButton className="content-actions__button" iconId="close" />

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

  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; } } }
  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; } } }
  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?
  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?
  38. Si tratta del modo più flessibile di gestire eccezioni Cosa

    funziona
  39. Cosa decisamente no 1. Gli stili originali possono essere sovrascritti

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

    may be too small? Modificatori ad hoc
  41. <Dialog className="dialog--user-intent"> <!-- [...] --> </Dialog>

  42. <Dialog className="dialog--user-intent"> <!-- [...] --> </Dialog>

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

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

    } }
  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?
  46. Questa pratica permette una discreta flessibilità, offrendo controllo e mantendendo

    le varianti co-locate nel codice. Cosa funziona
  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
  48. Pattern specializzati I'm special

  49. <Dialog className="dialog--prompt"> <!-- [...] --> </Dialog>

  50. <Dialog className="dialog--prompt"> <!-- [...] --> </Dialog>

  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; } }
  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
  53. I pattern sono al centro della conversazione: non si tratta

    di casi speciali, ma di versioni predefinite dei componenti base. Cosa funziona
  54. Cosa decisamente no 1. Potrebbe portare ad astrarre troppo presto

    2. Copre un numero ridotto di eccezioni
  55. <Dialog type="prompt" /> <Dialog className="dialog--prompt"> <!-- [...] --> </Dialog> <DialogPrompt

    />
  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
  57. Basically Sono bloccato

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

    Kholmatova · June 2015
  59. Il problema Come facciamo a riutilizzare i nostri pattern quando

    l'use case è un po' diverso?
  60. Cosa sto cercando di risolvere?

  61. Posizionamento nel parent component

  62. <div className="game-intent__dialog"> <Dialog> <!-- [...] --> </Dialog> </div>

  63. <div className="game-intent__dialog"> <Dialog> <!-- [...] --> </Dialog> </div>

  64. //_dialog.scss .dialog { width: 100%; height: 100%; //[...] } //_game-intent.scss

    .game-intent { //[...] &__dialog { width: 43.75rem; height: auto; } }
  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à
  66. Questa pratica definisce responsabilità precise in modo chairo e crea

    la possibilità di avere implementazioni specifiche senza invalidare i pattern. Cosa funziona
  67. <div className="custom-class"> <Dialog> <!-- [...] --> </Dialog> </div> <Dialog className="custom-class">

    <!-- [...] --> </Dialog>
  68. Cosa decisamente no Si creano una serie di wrapper che

    non sarebbero serviti altrimenti.
  69. Posizionamento in relazione ad altri componenti

  70. <Dialog className="space-max inner-space-min"> <!-- [...] --> </Dialog>

  71. <Dialog className="space-max inner-space-min"> <!-- [...] --> </Dialog>

  72. Riduce la necessità di inventarsi nuove classi e sposta la

    conversazione sui rapporti tra gli elementi a livello di pattern library. Cosa funziona
  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?
  74. Componenti 
 "aperti"

  75. //_question-content-block.scss .question-content-block { //[...] &__icon-button { //[...] .icon { width:

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

    $content-block-icon-large-size; height: $content-block-icon-large-size; } }
  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; } }
  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; } }
  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
  80. <Icon size={32} />

  81. 1. Ogni componente base può essere flessibile quanto necessario. 2.

    Gli sviluppatori hanno controllo rispetto a quali "specializzazioni" offrire. Cosa funziona
  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?
  83. Basically Does it get easier?

  84. None
  85. The more you know who you are and what you

    want, the less you let things upset you
  86. I just don't know what I'm supposed to be

  87. “A common language is a first step towards communication across

    cultural boundaries. ” Ethan Zuckerman
  88. Il problema Come facciamo a riutilizzare i nostri pattern quando

    l'use case è un po' diverso?
  89. Il problema Come capire – ed espiremere – il significato

    di un'eccezione nei pattern?
  90. Cercando ci capire cosa 
 si sta costruendo

  91. Facendosi coinvolgere prima