Proposta para modularizar o userscript

[CaioWzy]

Esta issue tem o objetivo de promover uma discussão acerca da dificuldade de manutenção e modularização do userscript, e, se necessário for, procurarmos meios de dividir a responsabilidade em vários arquivos separados e organizados.

O que proponho aqui é que refatoremos todo o código e mantenhamos as funções básicas e principais no arquivo principal. Também, o código de cada site no seu próprio arquivo e, no final, todo o código é importado pelo arquivo principal pelo @require.

Também é possível utilizarmos um pré-processador e compilar tudo em um único arquivo durante a build.

Todos estão convidados para participar desta discussão.

[CaioWzy]

Um adendo, seria interessante que os 'perfis' dos sites pudessem também ser 'compilados' tanto para o userscript quanto para a extensão, de acordo com a compatibilidade de cada. Assim, faríamos o trabalho uma única vez.

[rodorgas]

Essa proposta é necessária!

Uma decisão importante é @require vs pré-processador. Estou inclinado a preferir o @require, porque o código não fica tão longo e difícil de ler para o usuário, quanto um pré-processado ficaria. No entanto dá mais trabalho pro usuário investigar o fonte, pois será necessário olhar em cada URL.

De qualquer forma, ler o fonte pelo userscript vai ser uma experiência ruim, o ideal é clonar o repositório mesmo. Eu acho que com @require é um pouco mais limpo e vai nos poupar de trabalho adicional para configurar webpack ou um script custom. O que você acha?

[CaioWzy]

Lembrando que para o caso do @require, provavelmente, teríamos de deixar todos os arquivos da build no release (cada script requerido) e gerar o script principal apontando para os arquivos na release da mesma versão.

…

On Wed, Sep 18, 2019, 10:23 PM Rodrigo Orem ***@***.***> wrote: Essa proposta é necessária! Uma decisão importante é @require vs pré-processador. Estou inclinado a preferir o @require, porque o código não fica tão longo e difícil de ler para o usuário, quanto um pré-processado ficaria. No entanto dá mais trabalho pro usuário investigar o fonte, pois será necessário olhar em cada URL. De qualquer forma, ler o fonte pelo userscript vai ser uma experiência ruim, o ideal é clonar o repositório mesmo. Eu acho que com @require é um pouco mais limpo e vai nos poupar de trabalho adicional para configurar webpack ou um script custom. O que você acha? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10?email_source=notifications&email_token=AC6QPH2QVFS5OMEWZGWW7KTQKLIB7A5CNFSM4IURZZGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7B45OI#issuecomment-532926137>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC6QPHZFB2GZQFJCB5IEHATQKLIB7ANCNFSM4IURZZGA> .

[rodorgas]

Seria meio esquisito 20 arquivos em cada release hahaha, mas acho que dá pra fazer. Serão arquivos pequenos também. Não parece um problema, exceto pelo fato de ser pouco usual.

[CaioWzy]

Pensei em outra forma legal de fazer isso, que tal:

Ao gerar a build, o script consulta os arquivos a serem incluídos e os referencia usando a API raw + tag, exemplo. Então, gera o arquivo principal contendo referências @require e envia somente ele ao releases.

Assim, um único arquivo ficaria responsável por puxar do repositório o resto dos arquivos, como está delimitado por tag não haverá problema quando fizemos alterações posteriores.

[requeijaum]

Modularizar de acordo com hostnames? É isso?
Aí um pré-processador se encarregaria de incluir os recursos seja para a extensão ou userscript?
Claro que tem que haver uma API básica pra conseguir simplificar ainda mais... como arquivos: general.js (pra funcionalidade geral) e hosts/huffpost.com.js - algo assim?

[CaioWzy]

Exatamente. Estava pensado em aproveitar a ideia e criar um modelo comum que poderá ser lido pela extensão e userscript, assim, teríamos um único trabalho.