vindi-ds-components
v3.15.3
Published
Projeto de componentes da Vindi
Downloads
13,659
Readme
DS Repositories Components
Um Design System é um conjunto de componentes reutilizáveis, documentos e testados.
Utilizamos React para manipular os componentes, Material UI como base e o Storybook para documentação.
Para publicar os componentes utilizamos o NPM.
Lançamentos
Para ver o que mudou na última versão lançada do projeto, e acompanhar as versões do projeto, basta acessar o link abaixo.
Primeiros passos
Instalação
Para instalar o pacote em um projeto RoR, é preciso que o sistema seja configurado com as gems:
- webpack
- react-rails
- yarn (opcional)
Passo a passo para instalação:
- Webpack: https://github.com/rails/webpacker
- React: https://github.com/reactjs/react-rails
Exemplo mais detalhado: recurrent/design-system
Configuração do webpacker
Por padrão, o webpack gera um output com o nome da aplicação + hash
para versionar melhor os arquivos. Contudo, a cada novo output desse maneira, deixa inconsistente os pacotes instalados. Para resolver isso, altere o arquivo config/webpack/environment.js
com as seguintes instruções:
// config/webpack/environment.js
const { environment } = require('@rails/webpacker')
environment.config.set('output.filename', '[name].js') //Adicionar essa linha
module.exports = environment
Após ambiente configurado, instale o pacote:
yarn add vindi-ds-components
Configurações iniciais
Ao adicionar o projeto os componentes, precisamos configurar as fontes do DS. Para isso, adicione ao
application.html.erb
(ou arquivos raíz do layout) o link abaixo:
<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;700&display=swap"
rel="stylesheet">
Construindo primeiro componente com DS
Para que as configurações sejam aplicadas os seu componente, é preciso envolver o seu componente com o Container
que vem no pacote vindi-ds-components
, semelhante a esse exemplo:
import { Theme } from 'vindi-ds-components'
function Page(){
return (
<Theme>
/* Seus componentes */
</Theme>
)
}
Em houver a necessidade de utilizar ícones, utilize o pacote vindi-ds-icons
:
import { Theme } from 'vindi-ds-components'
import { VdVindiColor } from 'vindi-ds-icons'
function Page(){
return (
<Theme>
<VdVindiColor width={108} height="auto" />
/* Seus componentes */
</Theme>
)
}
Para mais informações, acesse a documentação de ícones.
Com essas configurações realizadas, basta seguir o seu protótipo. 🎉
Para acesso a mais componentes, acesse a documentação de componentes.
Configuração do serviço de comunicação à API
O serviço recomendando para comunicação frontend/backend é o Axios. Para mais instruções de instalação e utilização acesse a documentação;
Desenvolvimento
Esse projeto está configurado para ser executado através do docker-compose
.
Serviço
Para iniciar o serviço utilize:
docker-compose build
docker-compose up
Dependências
Para instalar novas dependências utilize:
docker-compose run --rm web npm install packpage-name
Para atualizar todas as dependências utilize:
docker-compose run --rm web npm install
Contribuição do projeto
O projeto conta com ferramentas que validam a semântica do código, mas também do commit.
Commit com commitlint
Com o commitlint instalado e configurado com o husky, instruções são executadas antes e durante o commite, sendo:
- pré-commit: Valida se o lint está sem necessidade de alterações
- commit-msg: Valida se a mensagem está no padrão
commitlint
Para gerar um commit padronizado, o boilerplate disponibiliza o comando: npm run gc
. Ele auxilia na contrução da mensagem do commit. O padão aceitado pelo commitlint é similar a esse:
fix: mensagem sem letras maiusculas
Caso não queria colocar alguma das parte do commite, utilize :skip
, contudo é necessesário escolher o tipo (fix
) e o subject
(mensagem do commit, mesma -m "mensagem sem letras maiusculas"
. Para mais detalhes no link
Push
Antes de publicarmos uma branch, serão rodados os testes do projeto antes da publicação.
Repositório no NPM
Para acessar o repositório no NPM, basta acessar o link abaixo;
Visionamento:
Utilizamos o SEMVER para atualizarmos o projeto, com isso a versão deve ser alterada quando:
- major: quando a alteração deixar parte, ou todo, o pacote deixando incompatível as versões anteriores
- minor: ao incrementarmos com algum componente e com uma nova versão das lib ou tokens.
- patch: incrementos de baixo impacto ou correção de falhas.
Pronto, uma nova versão do Design System deve ter sido publicada.
PS.: Utilize o
docker-compose exec
para fazer a publicação, pois odocker-compose run --rm
perde a referência do login.
Storybook
Para acessar a biblioteca de componentes, basta acessar o link abaixo;