Component structure unification between dev & design

[yceballost]

Acercar la categorización que hay en la documentación y librerías de diseño con respecto a lo que existe en storybook.

Pueden existir licencias en la parte tech y en la parte de diseño.

Mirar si hay componentes que se llamen diferentes, aunque no debería es una organización más de categorías por encima

• Update storybook panel
• Update brand factory
  • Remove unnecessary levels
• Update external links pointing to brand factory

[yceballost]

https://gist.github.com/aweell/1b1470b3e2563e13bbfb4d541f03e936

[yceballost]

Añado la tag de Breaking Change porque romperemos url de Brand factory muy posiblemente

[aweell]

Storybook update in: Telefonica/mistica-web#502

[aweell]

Con respecto a brand-factory, queremos agrupar aquellos elementos que ahora caen dentro de la categoría patterns en storybook en una categoría aparte también?

Serían:

• Empty states
• Feedbacks
• Toda la parte relativa a forms que ahora vive dentro de input fields

[yceballost]

Con respecto a brand-factory, queremos agrupar aquellos elementos que ahora caen dentro de la categoría patterns en storybook en una categoría aparte también?

Serían:

• Empty states
• Feedbacks
• Toda la parte relativa a forms que ahora vive dentro de input fields

deberíamos

Cómo incorporaríamos cosas como Global Checkout / Walkthroughs / etc ?

[aweell]

Con respecto a brand-factory, queremos agrupar aquellos elementos que ahora caen dentro de la categoría patterns en storybook en una categoría aparte también?
Serían:

• Empty states
• Feedbacks
• Toda la parte relativa a forms que ahora vive dentro de input fields

deberíamos

Cómo incorporaríamos cosas como Global Checkout / Walkthroughs / etc ?

Las incluiría en esa categoría patterns también. (Incluyendo disabled states que ahora está en fundamentals y la movería)

[AnaMontes11]

Con respecto a brand-factory, queremos agrupar aquellos elementos que ahora caen dentro de la categoría patterns en storybook en una categoría aparte también?
Serían:

• Empty states
• Feedbacks
• Toda la parte relativa a forms que ahora vive dentro de input fields

deberíamos
Cómo incorporaríamos cosas como Global Checkout / Walkthroughs / etc ?

Las incluiría en esa categoría patterns también. (Incluyendo disabled states que ahora está en fundamentals y la movería)

Incluirías los disabled states ahí? no sé si lo veo dentro de patterns, la verdad

[aweell]

Con respecto a brand-factory, queremos agrupar aquellos elementos que ahora caen dentro de la categoría patterns en storybook en una categoría aparte también?
Serían:

• Empty states
• Feedbacks
• Toda la parte relativa a forms que ahora vive dentro de input fields

deberíamos
Cómo incorporaríamos cosas como Global Checkout / Walkthroughs / etc ?

Las incluiría en esa categoría patterns también. (Incluyendo disabled states que ahora está en fundamentals y la movería)

Incluirías los disabled states ahí? no sé si lo veo dentro de patterns, la verdad

En la documentación se define como una "solución transversal", al final lo que define es la manera en la que los disabled states se pintan en el ecosistema mística, lo equiparo a cómo se muestran los errores o se provee feedback. Quizás dentro de esa categoría fundamentals encajo aquellos aspectos que son los pilares sobre lo que se construye el sistema, color, tipografía, espaciado, que sí, también son transversales, pero no concretizan cómo se comporta un componente (o un grupo de ellos) y por eso algo más específico como la definición de un estado se me queda colgando.

Quiero matizar que aquí debatiría sobre si cada componente debe mostrar su estado disabled en su documentación, pero entiendo la solución, si todos hacen lo mismo, para que ponerlo en cada uno. (No abro debate sobre si todos deberían mostrarse igual)

Entiendo esa categoría patterns como:

[Cuando se da éste caso = aplico esta solución]

...

Cuando hay un error general = muestro un feedback de error
Cuando un elemento no esta disponible para interacción = lo muestro desabilitado
Cuando tengo que pedir datos = construyo un formulario de x manera
Cuando tengo un proceso de pago = lo estructuro de ésta manera