Flexibility

[turolopezsanabria]

Flexibility is a very recurrent topic for both Development and Design community, so we will sync to revisit our agreements.

This is a simplified version of our current agreements

• SUI is way more than components, we always take into consideration the complete SUI Universe including tools
• Although it's heavily designed and developed by and for Adevinta, SUI is Open Source
• SUI is our standard way of designing and developing our digital products in Adevinta (for Web)

Styles

• All components have a base look and feel: SUI Theme
• All styles can be customised using a Theme
• If any value is not open to customisation we can iterate the code to allow it
• Anyone can propose a new variation to improve the components (another size, colour, etc)

Functionalities

• All components provide a set of options to pick from (sizes, colours, etc)
• The dev/user of the component can use as many options as available in the props. If an option is requested but it's not provided by the component (a new size for instance) anyone can propose an iteration to include it.
• If an iteration need is widely requested, it will be included in SUI
• If the requested iteration is not widely needed (something really custom to a brand), it will not be included in SUI, and the brand has to build it as Snowflake or Drop of Water.
• Adding classNames Is not allowed
• Prop spreading is not allowed
• Adding styles wrapping the component in your own brand is not recommended

Facts

• These agreements are not perfect
• Our agreements limit some important things and we need to break the rules to code some stories
• Although it's not recommended to style components "from the outside" using a className, it still happens
• Iterating a component is still perceived as expensive compared to tricking the system

Ideas brainstorming to be more flexible

• Allow classNames
• Allow props spreading
• Allow props spreading but constrain classNames
• Radical flexibility
• forwardRef
• Edit element name – Tag? As?

Pros and Cons of being more flexible than today

Pros

• Will allow using SUI for some stories we can't write as today
• Improve Open Source and community
• Will allow using SUI for corner cases that fall outside SUI standards (a one time button, or special size of any component)

Cons

• Coding Ad hoc solutions for your brand is not a benefit for the rest of users of SUI
• We currently don't have capacity to maintain a huge OpenSource usage
• Undocumented Props
• Expected decrease of visits to SUI Demos
• Expected decrease of iterations of SUI Component
• Enumerators - Enumerator-generators (should it be closed or should we make an extendible one?

Stuff we should do regardless of this discussion

• Continue having these conversations regularly
• Make strong emphasis and frequent reminders on our ideation and collaboration processes
• Have an holistic conversation, not focused only on props spreading
• Revisit all components and make sure the Native properties of components are available without the need of a component iteration (aria-label for instance)
• If the previous point is met, we would need to document just our custom Props (sizes, types, and the long etc)
• We should differentiate between presentational and implementation discussion (visual vs technical)
• We need to define and include in our agreement what to do in a corner case, when we don't have other choice but breaking the agreement.
• Boolean Props:
  • we need to make sure we use "isWhatever" instead of "withWhatever".
  • is[Whatever] prefix is reserved for boolean props. [Whatever] must be written semantically affirmative. ( isHiddenVisible)

[turolopezsanabria]

hey hey, a very interesting input from @beatrizip during the weekly #1639
You can watch it here

In some cases, such as in Grid, adding a className is the smartest thing to be done. It would save a lot of headaches with minimum effort and zero risk of breaking the rules and agreements we currently have.

[turolopezsanabria]

Algunos objetivos de la reunión:

• objetivos claros y longevos
• agreements evitando corner cases no deseados
• agreements teniendo en cuenta las opiniones de todos
• Android developer MA - puntos de vista Native
• iOS DEveloper MA -
• Entender, seguir aprendiendo y seguir entregando consistencia
• buscar que SUI sea más fácil de lo que es ahora
• conocer el proceso de trabajo y acuerdos actuales
• ver la parte de flexibilidad, y los agreements
• conseguir acuerdos que nos hagan la vida más sencilla a los devs, y que hablemos el mismo idioma con UX
• luchar por la inflexibilidad
• alinearme en el uso de SUI Components y saber cómo iterarlos
• coger inputs para el equipo
• conocer los acuerdos
• ponerme al día, dark theme y prepararme para quitar el dark de Pro
• terminar de entender las herramientas de la casa, y entender cómo implementarlo en Advertising
• conseguir un buen tradeoff para agilizarnos y que se puedan reaprovechar