Open andrepg opened 2 days ago
Name | Link |
---|---|
Latest commit | 25f31e1f773f947e01415e863c352b34dc4d74da |
Latest deploy log | https://app.netlify.com/sites/diciotech/deploys/671e96c634941e0008cabc64 |
Deploy Preview | https://deploy-preview-257--diciotech.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
Por curiosidade, por que acha melhor um script por fora pra isso, ao invés de ler tudo em javascript?
Por curiosidade, por que acha melhor um script por fora pra isso, ao invés de ler tudo em javascript?
Foi uma decisão mais “cômoda”, por assim dizer. Já existe um scritpt Python que faz a manipulação dos arquivos e no repositório, dentro do meu estudo, parecia mais tranquilo trabalhar como este arquivo e gerar o JSON final para manter o código de leitura do JSON intocado.
Então, peguei a ideia emprestado e comecei a trabalhar nesse sentido. Isso evitou modificações no que já está funcionando e nos permite criar várias linguagens diferentes dos termos, já que basta passar um argumento para script.
O problema disso é que ele não tá integrado ao CI e precisa ser rodado manualmente. Pra dar cabo de todos os usos possíveis tem que adicionar ele num GitHub action pra rodar automaticamente. Mas toda vez que ele for rodado ele vai gerar um novo arquivo, que aí precisa também ser versionado.
Inclusive isso é feito atualmente no sass e não sei se é a melhor opção. O ideal é que tanto esse arquivo integrado quanto os arquivos css não fossem versionados e sempre gerados a partir do sass e dos arquivos individuais de letras nesse caso. Mas acho que isso precisa ser discutido melhor.
Bom ponto. A minha ideia foi justamente utilizar o CI, já que andei observando o trabalho de vocês e havia alguns scripts para rodarem assim (formatação e hooks).
Confesso que não considerei a integração com Netlify. E, hoje, está em Python. Mas, transformar este script para JS ou até mesmo implementar um sistema de build Vite não é complicado. O raciocínio lógico (que era o mais importante para mim) está pronto. Agora com este código funcionando é possível adaptar.
A minha ideia principal era não tocar no cards_pt-br.json e tratá-lo como um asset. Daí a transferência dos termos para outra pasta sem relação com a public
. Deixando para a build a responsabilidade de gerar o arquivo de cards antes do deploy (e isso mataria aquele problema de conflito).
Por outro lado, temos os termos já separados em letras na estrutura proposta. Agora a gente invoca a @levxyca para dar uma terceira visão.
Descrição de PR
Cria script para ler pastas com termos e gerar arquivo de dicionário.
Issue relacionado
256
171
Motivações
Buscando aquilo discutido na #171, este PR visa incluir um modo automatizado de construir o dicionário de termos e permitir melhor manutenção do conteúdo.
Informações adicionais
A ideia inicial consistia em um script JavaScript para coletar as informações e juntar na renderização. Após verificar commits recentes e novas implementações do GH Actions e Git hooks, optei por seguir de outra forma.
Assim, evitamos tocar o código relacionado à leitura dos cards. Vamos, em vez disso, trabalhar na geração do arquivo-fonte para este código.
O
generator.py
recebe dois argumentos e faz a leitura dos termos na pasta correspondente, para gerar, ao final, um dicionário no mesmo modelo do arquivocards_pt-br.json
que hoje existe.Os argumentos são
-l/--language
: código da linguagem (e nome da pasta fonte dos arquivos)-o/--output
: caminho de dump do dicionário em JSON, após processamento