Closed trupakufi closed 11 months ago
vercel[bot]
commented
11 months ago The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| aosf-website-63v9 | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Sep 23, 2023 1:55pm |
aosccode
commented
11 months ago @trupakufi Obrigado pela PR. Bom saber sobre o teu interesse em contribuir.
cc: @mraguinaldo @PedroFrancoDev reviews?
trupakufi
commented
11 months ago @trupakufi Obrigado pela PR. Bom saber sobre o teu interesse em contribuir.
cc: @mraguinaldo @PedroFrancoDev reviews?
É com muito prazer.
trupakufi
commented
11 months ago Segundo o princípio Self-Documenting Code, um código deve ser claro, legível e servir como documentação, reduzindo a necessidade de outros desenvolvedores buscarem documentações, ou mesmo comentários adicionais.
Ao fazeres o uso desta sintaxe, o código importa de algum arquivo index.{jsx | js | tsx | ts} pelo componente Contributor import { Contributor } from "..";
E isto é ruim, porque logo de cara ele não conseguirá determinar por onde está sendo importado este Objecto.
Já a primeira abordagem, ela sugere e indica a localização do componente Contributor dentro do directório ./contributor, poupando a carga cognitiva do dev, ele pode até nem saber se esta pasta se encontra em ./src ou ./components mas sabe que deve procurar o arquivo na pasta ./contributor ou contributor.tsx
import { Contributor } from "../contributor";
Na realidade não é ruim, a partir do momento que sempre que tiveres algo como "." ou ".." logicamente para quem já sabe conceitos base da linguagem vai entender que claramente o "." significa que está na mesma pasta dentro de um index e o ".." significa que está uma pasta acima, é coeso evitar relações diretas entre arquivos, e importando diretamente dos arquivos estás a acoplar muito os arquivos e as funções, caso algum dia mudes um nome e esqueças de mudar noutro lugar recebes um erro em vários lugares, diferente dum ambiente onde todo mundo importa de um lugar, nesse caso, o index, e esse index é o único que sabe o verdadeiro nome e localização da coisa.
Menos acoplamento e mais coesão e consistência nas importações.
trupakufi
commented
11 months ago Não vejo motivos para usar a directive "use client" nesta página. Tem algum motivo claro para usar neste local e ocasião ?
Não consigo ver o arquivo, mas só para que conste, os lugares em que adicionei "use-client" foi porque algum outro requisito me obrigou, no caso do arquivo page, o StylesheetManager que usaram é Client Only porque cria um contexto e contextos não existem no servidor, daí o uso do "use-client" e em casos dos componentes, teve problemas com coisas como "useEffect" que é totalmente client também, e pediu para adicionar o "use-client" também. No caso do "use-client" não pus por simples vontade, foram erros que me levaram a usar nos lugares em que adicionei.
trupakufi
commented
11 months ago porque mover o "postcss": "8.4.29", para devDependencies?
se os proprios criadores na doc recomendam instalar assim npm i postcss ou yarn add postcss
Fui ler a documentação e reparei que não tem efeito em produção porque transpila o código para CSS mais específico e achei melhor deixar ele como dev, mas é tudo uma sugestão, vocês têm o poder de decidir e editar.
trupakufi
commented
11 months ago Modo estrito do Reacté um recurso exclusivo do modo de desenvolvimento para destacar possíveis problemas em um aplicativo. Ajuda a identificar ciclos de vida inseguros, uso de API herdada e vários outros recursos.
https://nextjs.org/docs/app/api-reference/next-config-js/reactStrictMode
Muito estranho isso, eu por acaso removi porque o Próprio Next em modo desenvolvimento disse que não está na lista das propriedades permitidas, daí que o meu commit foi bem específico até.
Danguya
commented
11 months ago Segundo o princípio Self-Documenting Code, um código deve ser claro, legível e servir como documentação, reduzindo a necessidade de outros desenvolvedores buscarem documentações, ou mesmo comentários adicionais. Ao fazeres o uso desta sintaxe, o código importa de algum arquivo index.{jsx | js | tsx | ts} pelo componente Contributor import { Contributor } from ".."; E isto é ruim, porque logo de cara ele não conseguirá determinar por onde está sendo importado este Objecto. Já a primeira abordagem, ela sugere e indica a localização do componente Contributor dentro do directório ./contributor, poupando a carga cognitiva do dev, ele pode até nem saber se esta pasta se encontra em ./src ou ./components mas sabe que deve procurar o arquivo na pasta ./contributor ou contributor.tsx import { Contributor } from "../contributor";
Na realidade não é ruim, a partir do momento que sempre que tiveres algo como "." ou ".." logicamente para quem já sabe conceitos base da linguagem vai entender que claramente o "." significa que está na mesma pasta dentro de um index e o ".." significa que está uma pasta acima, é coeso evitar relações diretas entre arquivos, e importando diretamente dos arquivos estás a acoplar muito os arquivos e as funções, caso algum dia mudes um nome e esqueças de mudar noutro lugar recebes um erro em vários lugares, diferente dum ambiente onde todo mundo importa de um lugar, nesse caso, o index, e esse index é o único que sabe o verdadeiro nome e localização da coisa.
Menos acoplamento e mais coesão e consistência nas importações.
Irmão código limpo não tem nada haver com a linguagem, mas sim com clareça no codigo, encurtar o modo de importar os arquivos não tem nada haver com acoplamento, um coisa é adicionar uma directiva que encurte o modo de importação e outra é separar funcões e objectos por arquivo.
trupakufi
commented
11 months ago Modo estrito do Reacté um recurso exclusivo do modo de desenvolvimento para destacar possíveis problemas em um aplicativo. Ajuda a identificar ciclos de vida inseguros, uso de API herdada e vários outros recursos. https://nextjs.org/docs/app/api-reference/next-config-js/reactStrictMode
Muito estranho isso, eu por acaso removi porque o Próprio Next em modo desenvolvimento disse que não está na lista das propriedades permitidas, daí que o meu commit foi bem específico até.
Segundo o princípio Self-Documenting Code, um código deve ser claro, legível e servir como documentação, reduzindo a necessidade de outros desenvolvedores buscarem documentações, ou mesmo comentários adicionais. Ao fazeres o uso desta sintaxe, o código importa de algum arquivo index.{jsx | js | tsx | ts} pelo componente Contributor import { Contributor } from ".."; E isto é ruim, porque logo de cara ele não conseguirá determinar por onde está sendo importado este Objecto. Já a primeira abordagem, ela sugere e indica a localização do componente Contributor dentro do directório ./contributor, poupando a carga cognitiva do dev, ele pode até nem saber se esta pasta se encontra em ./src ou ./components mas sabe que deve procurar o arquivo na pasta ./contributor ou contributor.tsx import { Contributor } from "../contributor";
Na realidade não é ruim, a partir do momento que sempre que tiveres algo como "." ou ".." logicamente para quem já sabe conceitos base da linguagem vai entender que claramente o "." significa que está na mesma pasta dentro de um index e o ".." significa que está uma pasta acima, é coeso evitar relações diretas entre arquivos, e importando diretamente dos arquivos estás a acoplar muito os arquivos e as funções, caso algum dia mudes um nome e esqueças de mudar noutro lugar recebes um erro em vários lugares, diferente dum ambiente onde todo mundo importa de um lugar, nesse caso, o index, e esse index é o único que sabe o verdadeiro nome e localização da coisa. Menos acoplamento e mais coesão e consistência nas importações.
Irmão código limpo não tem nada haver com a linguagem, mas sim com clareça no codigo, encurtar o modo de importar os arquivos não tem nada haver com acoplamento, um coisa é adicionar uma directiva que encurte o modo de importação e outra é separar funcões e objectos por arquivo.
E quem falou que código limpo tem haver com linguagem ? Isso nem sequer é uma diretiva, e eu não encurtei a importação, eu só deixei de importar directo do arquivo e adicionei algo um exporter geral para as pastas. Nada tão estranho aí, não tem complexidade nisso, fica muito mais claro assim do que ter imports para um monte de pastas, e se reparares isso funciona muito bem com os imports relativos, só tem vantagem, não tem história, quanto menos texto nos imports melhor, para a percepção.
Refactor & Code Improvements
Peço imensas desculpas por não ter aberto uma ou várias issues primeiro, mas espero que me entendam. Não consegui abrir uma Issue porque eu decidi melhorar o código e a organização, a princípio não sabia por onde começaria e saí organizando e melhorando o que encontrava e deu em tudo isso.
Mas de uma forma bem específica melhorei coisas como:
Ainda faltou mais e vou continuar melhorando o que puder. Mas por agora, espero que gostem. E espero ter ajudado. Caso fiquem com alguma dúvida do porquê que fiz alguma coisa em alguma parte do Website, só mencionar na review e respondo e caso contrário podem editar.