Certifique-se de ter o Node.js instalado em sua máquina. (versão do node utilizada: v18.17.0)

Abra o terminal e navegue até o diretório do projeto.

Execute o seguinte comando para instalar as dependências:

npm install

Execute o comando para rodar o ambiente de desenvolvimento Vite:

npm run dev

Este comando iniciará o servidor de desenvolvimento e você poderá acessar o aplicativo em http://localhost:3000

Execute o comando para rodar os testes unitários:

npm run test

Execute o comando para rodar o Storybook do projeto:

npm run storybook

Abaixo segue alguns tópicos relacionados ao raciocínio e decisões utilizados durante o processo de desenvolvimento.

• O ideal é que um DS seja um projeto separado e considerado uma lib de UI/UX. Por exemplo publicar ele como um pacote no npm para que seja possível importar ele nos projetos que você ou o time deseja. Neste desafio eu tomei a decisão de fazer a página de News dentro do repositório do DS. Como disse acima o ideal é ter dois projetos separados, cada um em um repositório e assim importar o DS como uma dependencia do projeto.
• Existem algumas situações que o DS precisa ser agnóstico a framework. Isso é possível utilizando o StencilJS (https://stenciljs.com/). Com o StencilJS você desenvolve o DS e consegue exportar como web components e assim utilizar em qualquer um dos frameworks/libs web que você e sua equipe trabalham. Eu decidi utilizar o react, apesar de possuir domínio em Angular, decidi usar o react para ajudar a reforçar alguns aprendizados que obtive nesses ultimos meses.
• Utilizei o typescript para melhorar a organização, confiabilidade e manutenção dos projetos em JS.
• Decidi alterar a variavel de cor que está sendo indicada no figma para ficar visualmente semelhante ao botao também exibido no figma (de $brand-color-primary-2 para ...primary-5)
• Para o Heading e Subtitle levei em consideração que pode existir mais de um tamanho, por conta disso adicionei a prop size. Porém como no figma só tem o tamanho small, considerei ele como default e não criei mais nenhuma variação.
• A mesma lógica foi aplicada no componente button. Já que comumente se utiliza algumas variações como primary, secondary e etc.
• Algumas variáveis no figma estão desatualizadas com o json enviado, por conta disso tomei a decisão de escolher outras variáveis que faziam sentido de acordo com o layout no figma (exemplo: padding do shape 40px, cor da borda do shape $neutral-color-2)
• No componente <Heading> optei por usar a tag <H2> já que o card pode ser utilizado e renderizado várias vezes na mesma página. Em uma página é boa prática ter apenas um <H1> (Referencia: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements#avoid_using_multiple_h1_elements_on_one_page).
• O React está rodando em strict mode. Por conta disso, no ambiente de dev, ele acaba gerando uma duplicação das chamadas de API (https://beta-reactjs-org-git-effects-fbopensource.vercel.app/learn/synchronizing-with-effects#fetching-data). Não se assuste ao visualizar requests duplicados. :)
• O componente <Button> poderia ter a possibilidade de ser uma tag <button> ou <Link> (em casos de SEO é importante manter a semântica e também para evitar que o usuário ao clicar em um link carregue todo o site novamente) mas optei por manter a lógica do component simples considerando uso dentro de um site simples

• Analisar o problema proposto no teste.
• Pesquisar materiais da Meiuca falando sobre DS e analisar a perspectiva de construção e concepção de DS deles (exemplo de referencia: https://medium.com/meiuca/1-design-system-na-vis%C3%A3o-da-meiuca-cc0d67aa8d1b)
• Decidir qual tecnologia utilizar
• Criar a base do projeto e o primeiro componente
• Analisar como será a organização de pastas.
• Entender como fazer a leitura dos tokens.
• Leitura documentação Style Dictionary
• configuração e geração do build das variáveis de scss utilizando a lib do Style Dictionary
• Desenvolver os componentes
• Desenvolver página consumindo API do Google e renderizando as notícias utilizando componente <CardContent>

Alguns pontos que considero importante:

• Ao analisar os requisitos e materiais do teste já é possível obter uma boa condição para otimizar e manter o DS. Utilizar ferramentas como Figma, Style Dictionary e Storybook ajuda a manter as equipes envolvidas alinhadas com relação a definições.
• Falando em definições, apesar de usar as ferramentas acima, é importante que manter os tokens e toda documentação atualizada. Isso pode evitar eventuais inconsistencias entre os projetos e as definições de design da empresa.
• É importante manter uma boa comunicação entre o DS e os outros times. Sempre que possível colher feedbacks dos devs que estão utilizando o DS. Outra dica importante é acompanhar o uso do DS e colher métricas para tomar decisões mais acertivas.
• Outras ferramentas importantes é utilizar ESLint e Prettier para apoiar no dia a dia da manutenção e criação de novos componentes. Ajudando assim a manter a padronização do código.
• Para ajudar na consistencia do DS é importante criar testes automatizados dos componentes. Assim é possível garantir que ao adicoinar novos componentes ou corrigir algo o DS não corre risco de quebrar.
• Incluir o code review no processo de desenvolviemnto do time do DS também é muito importante.
• Outro detalhe seria consumir os tokens de maneira dinâmica

Esses são alguns pontos que considero importante. O DS assim é um projeto vivo que precisa constantemente adicionar novos componentes ou ajustar os que já existem. Então é importante seguir essas regras para garantir a manutenibilidade e consistencia