levxyca / diciotech

O Diciotech é um dicionário tech online colaborativo, construído com HTML, SASS e JavaScript, e open source. Nossa missão é ajudar pessoas de todos os níveis a entenderem termos e conceitos relacionados à tecnologia de forma clara e simples.
https://diciotech.netlify.app/
GNU General Public License v3.0
448 stars 80 forks source link

Cria gerador de dicionário modular #257

Open andrepg opened 2 days ago

andrepg commented 2 days ago

Descrição de PR

Há possibilidade de estes códigos precisarem de alterações para inclusão no CI e novo fluxo de formatação incluído (ou o contrário).

Cria script para ler pastas com termos e gerar arquivo de dicionário.

Issue relacionado

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 arquivo cards_pt-br.json que hoje existe.

Os argumentos são

⚠️ É importante notar que, da forma como construído, o script precisa estar dentro da pasta dicionario, pois lerá as pastas de forma relativa à sua execução. Podemos mudar se necessário.

netlify[bot] commented 2 days ago

Deploy Preview for diciotech ready!

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...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

george-gca commented 1 day ago

Por curiosidade, por que acha melhor um script por fora pra isso, ao invés de ler tudo em javascript?

andrepg commented 1 day ago

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.

george-gca commented 1 day ago

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.

andrepg commented 1 hour ago

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.