Tokens

[ffernandomoraes]

E ai,

Para fins de padronização, agilidade nos protótipos e consistência de dados, os designers criaram uma folha de tokens do Houston (https://docs.google.com/document/d/1lDcsSeSDGDDnPIfOjWAhT_i1E4D1ZHDdjoAbySbVzHk/edit?usp=sharing).

Além dos motivos citados acima, a ideia dos tokens é servir de suporte para as aplicações (em componentes personalizados, protótipos e etc..).

Com isso, do nosso lado (código) precisamos viabilizar isso em nossos estilos dos componentes e criadores de estilos (createUseStyles e styled).

Eis que surgem as dúvidas:

• Devemos separar os tokens em um package? Por exemplo: @eduzz/houston-tokens (Recebemos uma sugestão de colocar no @eduzz/houston-core).
• Devemos criar um package que trata os estilos juntamente com os tokens, ou o package deveria aceitar um theme personalizável? Exemplo do package: @eduzz/houston-styles
• As variáveis disponibilizadas para uso são com hífen ($spacing-inline-quarck), "não conseguimos" utilizar desta forma, como seria legal? CamelCase? Desenvolver uma solução que aceite a variável como string (margin: '$spacing-inline-quarck')? Criar objetos de multi-níveis (theme.spacing.inline.quark)?
• Inserir os tokens na lib de UI (@eduzz/houston-ui) e implementar por lá mesmo os ajustes nos criadores de estilos?
• Como deveria ser a implementação nos componentes?

  
  import { crateStyles, styled } from 'xpto';

const useStyles = crateStyles((theme) => ({ component: { margin: theme.$spacingInlineQuarck } }));

export function Component() { const classes = useStyles();

return (

) };

function Component2({ className }) { return (

); }

export default styled(Component2) margin: ${({ theme }) => theme.$spacingInlineQuarck}; ;

Enfim, estamos aberto a sugestões de como viabilizar isso (tanto onde colocar, quanto implementação no código).

JonathasRodrigues commented 2 years ago

Vou passar meu ponto de vista

• Devemos separar os tokens em um package? Por exemplo: @eduzz/houston-tokens (Recebemos uma sugestão de colocar no @eduzz/houston-core). Acho que um package separado para facilitar a manutenção e o reaproveitamento desse package (mesmo considerando que sempre será utilizado por esse design system).

• Devemos criar um package que trata os estilos juntamente com os tokens, ou o package deveria aceitar um theme personalizável? Exemplo do package: @eduzz/houston-styles Acho que o deveria aceitar um theme qualquer assim evitando o forte acoplamento (acho que cabe avaliar o esforço de cada alternativa, tempo x complexidade).

• As variáveis disponibilizadas para uso são com hífen ($spacing-inline-quarck), "não conseguimos" utilizar desta forma, como seria legal? CamelCase? Desenvolver uma solução que aceite a variável como string (margin: '$spacing-inline-quarck')? Criar objetos de multi-níveis (theme.spacing.inline.quark)? Acho que como objeto ficaria melhor, podemos adicionar IntelliSense para tornar mais simples de utilizar os tokens.

• Inserir os tokens na lib de UI (@eduzz/houston-ui) e implementar por lá mesmo os ajustes nos criadores de estilos? idono

• Como deveria ser a implementação nos componentes?

import { createStyles, styled } from 'xpto';

const useStyles = createStyles((theme) => ({
  component: {
    margin: theme.spacing.inline.quarck
  }
}));

export function Component() {
  const classes = useStyles();

  return (
    <div className={classes.component} />
  )
};

function Component2({ className }) {
  return (
    <div className={className} />
  );
}

export default styled(Component2)`
  margin: ${({ theme }) => theme.spacing.inline.quarck};
`;

ffernandomoraes commented 2 years ago

Atenção! As dúvidas levantadas na postagem são sugestões para gerar questionamentos. Vocês tem total liberdade de propor algo diferente. Não se prenda ou contamine como as mesmas.

miguelaugl commented 2 years ago

Top demais a proposta, essa parada de tokens é muito útil e mega importante.

Devemos separar os tokens em um package... e Devemos criar um package que trata os estilos juntamente com os tokens...

Acho que devíamos ter esse package @eduzz/houston-styles e com eles os tokens do Houston e permitir a customização de tema também.

As variáveis disponibilizadas para uso são com hífen... e Como deveria ser a implementação nos componentes?

Cara, tenho a sugestão da gente dar uma olhada no Stitches para usarmos no design system do Houston, é uma lib CSS-IN-JS que tem se mostrado muito poderosa, performática, leve e já possui suporte para theme tokens e inclusive poderíamos usar a sintaxe proposta pelo documento.

Um ponto que queria chamar atenção é na hora de implementarmos utilizarmos rem ao invés de px menos para bordas e sombras. A principal razão disso é acessibilidade já que o rem acompanha o font-size do navegador do usuário.

Sobre os tokens:

• Os spacings eu não entendi muito bem os casos de uso, normalmente usamos $spacing-1 ou $spacing-4 e controlamos onde aplicar pela própria propriedade margin, marginLeft, etc;
• Algumas sugestões de nomes que já vi e gostaria de saber o que acham:

  $border-width-n -> $border-n;
  $border-radius-n -> $rounded-n;
  $opacity-level-n -> $opacity-n;
  $shadow-level-1 -> $shadow-n;
  $font-weight-n -> $font-n (Exs: font-bold, font-semibold, isso porquê sabemos que font-bold não é tamanho de fonte);
  $font-size-n -> $font-n (Mesmo motivo acima);
  ${neutral, feedback, brand}color-x-y ->${neutral, feedback, brand}-x-y (basicamente sem o color);

JonathasRodrigues commented 2 years ago

@miguelaugl gosto do Stitches também, meu receio é em relação CSS-IN-JS que ja existe no material-ui (que esta sendo utilizado), como ficaria? estariamos colocando mais um bundle sendo que o material ui tem isso ja? Nunca cheguei a utilizar os 2 juntos, então é mais uma duvida mesmo.

sobre o rem acho que podemos falar com os cara do UI/UX

sobre os tokens o mercado hoje tem esse padrão que você mencionou mesmo, não sei qual é o verdadeiro propósito do houston em ter essas nomenclaturas, o proprio material.io, antd, spectrum (da adobe), seguem esse padrão, fica ai uma coisa a ser avaliada.

miguelaugl commented 2 years ago

@JonathasRodrigues a nova versão do MUI não tem uma styling engine própria deles mais né, não sei se você tava comentando da antiga mas o Houston já migrou pra v5 e usa o emotion. Hoje pela forma que o Houston tá feito, acho que não seria um problema trocar porque todos os componentes consomem da abstração que tem no styles.

E não sei quais os próximos planos do Houston, mas assim como foi feito com a Tabela, criarmos nossos próprios componentes sem depender do MUI pra mim é indispensável.

ffernandomoraes commented 2 years ago

Vi um pouco sobre o Stitches, achei legal, mas tenho meus receios também.

Sobre a unidade de medida REM, os designers já começam a cogitar sobre. Talvez eles já estejam atualizando haha Eu concordo 100%.

Sobre a nomenclatura das variáveis, também não gostei muito, achei um pouco redundante. Mas precisamos entender o lado deles e o por que fizeram desta forma. De repente foi o jeito mais fácil/escalavel que encontraram para inserir variaveis no Figma e usarem nos protótipos. Vale o questionamento.

danieloprado commented 2 years ago

Jesus chega de lib nova kkkk vamos ficar no emotion por favor kkk da para usar ele fora do muiu sem problemas se precisar.

Sobre as variáveis gosto da idéia de objeto com subniveis. os nomes acho que podem sem simplificados um pouco como o miguel falou ali, tem nomes muito extensos

Notlim38 commented 2 years ago

Boa tarde, pessoal!

Para manter a organização e alinhamento entre time de desenvolvimento e time de design, seguimos uma regra para criação de nomes de tokens e componentes do Houston. Acredito que irá ficar mais claro depois que derem uma olhada na regra. Segue abaixo:

[]s

ffernandomoraes commented 2 years ago

stand-by.

danieloprado commented 2 years ago

Resolved by #305

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[JonathasRodrigues]

Vou passar meu ponto de vista

• Devemos separar os tokens em um package? Por exemplo: @eduzz/houston-tokens (Recebemos uma sugestão de colocar no @eduzz/houston-core). Acho que um package separado para facilitar a manutenção e o reaproveitamento desse package (mesmo considerando que sempre será utilizado por esse design system).

• Devemos criar um package que trata os estilos juntamente com os tokens, ou o package deveria aceitar um theme personalizável? Exemplo do package: @eduzz/houston-styles Acho que o deveria aceitar um theme qualquer assim evitando o forte acoplamento (acho que cabe avaliar o esforço de cada alternativa, tempo x complexidade).

• As variáveis disponibilizadas para uso são com hífen ($spacing-inline-quarck), "não conseguimos" utilizar desta forma, como seria legal? CamelCase? Desenvolver uma solução que aceite a variável como string (margin: '$spacing-inline-quarck')? Criar objetos de multi-níveis (theme.spacing.inline.quark)? Acho que como objeto ficaria melhor, podemos adicionar IntelliSense para tornar mais simples de utilizar os tokens.

• Inserir os tokens na lib de UI (@eduzz/houston-ui) e implementar por lá mesmo os ajustes nos criadores de estilos? idono

• Como deveria ser a implementação nos componentes?

import { createStyles, styled } from 'xpto';

const useStyles = createStyles((theme) => ({
  component: {
    margin: theme.spacing.inline.quarck
  }
}));

export function Component() {
  const classes = useStyles();

  return (
    <div className={classes.component} />
  )
};

function Component2({ className }) {
  return (
    <div className={className} />
  );
}

export default styled(Component2)`
  margin: ${({ theme }) => theme.spacing.inline.quarck};
`;

[ffernandomoraes]

Atenção! As dúvidas levantadas na postagem são sugestões para gerar questionamentos. Vocês tem total liberdade de propor algo diferente. Não se prenda ou contamine como as mesmas.

[miguelaugl]

Top demais a proposta, essa parada de tokens é muito útil e mega importante.

Devemos separar os tokens em um package... e Devemos criar um package que trata os estilos juntamente com os tokens...

Acho que devíamos ter esse package @eduzz/houston-styles e com eles os tokens do Houston e permitir a customização de tema também.

As variáveis disponibilizadas para uso são com hífen... e Como deveria ser a implementação nos componentes?

Cara, tenho a sugestão da gente dar uma olhada no Stitches para usarmos no design system do Houston, é uma lib CSS-IN-JS que tem se mostrado muito poderosa, performática, leve e já possui suporte para theme tokens e inclusive poderíamos usar a sintaxe proposta pelo documento.

Um ponto que queria chamar atenção é na hora de implementarmos utilizarmos rem ao invés de px menos para bordas e sombras. A principal razão disso é acessibilidade já que o rem acompanha o font-size do navegador do usuário.

Sobre os tokens:

• Os spacings eu não entendi muito bem os casos de uso, normalmente usamos $spacing-1 ou $spacing-4 e controlamos onde aplicar pela própria propriedade margin, marginLeft, etc;
• Algumas sugestões de nomes que já vi e gostaria de saber o que acham:

  $border-width-n -> $border-n;
  $border-radius-n -> $rounded-n;
  $opacity-level-n -> $opacity-n;
  $shadow-level-1 -> $shadow-n;
  $font-weight-n -> $font-n (Exs: font-bold, font-semibold, isso porquê sabemos que font-bold não é tamanho de fonte);
  $font-size-n -> $font-n (Mesmo motivo acima);
  ${neutral, feedback, brand}color-x-y ->${neutral, feedback, brand}-x-y (basicamente sem o color);

[JonathasRodrigues]

@miguelaugl gosto do Stitches também, meu receio é em relação CSS-IN-JS que ja existe no material-ui (que esta sendo utilizado), como ficaria? estariamos colocando mais um bundle sendo que o material ui tem isso ja? Nunca cheguei a utilizar os 2 juntos, então é mais uma duvida mesmo.

sobre o rem acho que podemos falar com os cara do UI/UX

sobre os tokens o mercado hoje tem esse padrão que você mencionou mesmo, não sei qual é o verdadeiro propósito do houston em ter essas nomenclaturas, o proprio material.io, antd, spectrum (da adobe), seguem esse padrão, fica ai uma coisa a ser avaliada.

[miguelaugl]

@JonathasRodrigues a nova versão do MUI não tem uma styling engine própria deles mais né, não sei se você tava comentando da antiga mas o Houston já migrou pra v5 e usa o emotion. Hoje pela forma que o Houston tá feito, acho que não seria um problema trocar porque todos os componentes consomem da abstração que tem no styles.

E não sei quais os próximos planos do Houston, mas assim como foi feito com a Tabela, criarmos nossos próprios componentes sem depender do MUI pra mim é indispensável.

[ffernandomoraes]

Vi um pouco sobre o Stitches, achei legal, mas tenho meus receios também.

Sobre a unidade de medida REM, os designers já começam a cogitar sobre. Talvez eles já estejam atualizando haha Eu concordo 100%.

Sobre a nomenclatura das variáveis, também não gostei muito, achei um pouco redundante. Mas precisamos entender o lado deles e o por que fizeram desta forma. De repente foi o jeito mais fácil/escalavel que encontraram para inserir variaveis no Figma e usarem nos protótipos. Vale o questionamento.

[danieloprado]

Jesus chega de lib nova kkkk vamos ficar no emotion por favor kkk da para usar ele fora do muiu sem problemas se precisar.

Sobre as variáveis gosto da idéia de objeto com subniveis. os nomes acho que podem sem simplificados um pouco como o miguel falou ali, tem nomes muito extensos

[Notlim38]

Boa tarde, pessoal!

Para manter a organização e alinhamento entre time de desenvolvimento e time de design, seguimos uma regra para criação de nomes de tokens e componentes do Houston. Acredito que irá ficar mais claro depois que derem uma olhada na regra. Segue abaixo:

[]s

[ffernandomoraes]

stand-by.

[danieloprado]

Resolved by #305