Quero fazer uma reserva imediatamente de que este artigo não se destina a quem tem desenvolvimento frontend da atividade principal. Esta publicação destina-se a desenvolvedores de back-end que precisam urgentemente de fixar a interface da web ou aqueles que estão apenas interessados em novas áreas, bem como desenvolvedores de pilha completa.
Então, vamos ao problema. Lembro-me de
um artigo , e também, nos espaços abertos de Habr, havia vários outros semelhantes. Todos são apresentados como quadrinhos, mas como se costuma dizer "em toda piada há um grão de verdade", e aqui não há nem um pouco ... Mas aqui está a questão: qual a utilidade de todos esses quadros, eles são necessários?
A pergunta que eu gostaria de levantar é principalmente sobre montagem. É nesta fase que a comunidade js oferece um número incrível de ferramentas, cuja necessidade não é de todo óbvia. Por exemplo, a comunidade oferece várias opções para trabalhar com módulos, o que fazia sentido no momento, mas, no momento, a especificação de
importação /
exportação é suportada por todos os navegadores modernos, e mesmo não pelo navegador de borda. Como mencionamos anteriormente que não temos motivos para trabalhar com bibliotecas antigas, examinaremos as especificações de importação / exportação. Mas o que realmente precisamos é de algum tipo de trabalho com dependências.
Farei uma pequena digressão para explicar a escolha das tecnologias que serão usadas no exemplo para o frontend em si. Para não nos aprofundarmos na variedade de estruturas, vamos de um
padrão maravilhoso. Então, tudo está se tornando bastante simples, não há DOM virtual, há componentes da web. Isso pode estar terminado, mas ainda assim. Se decidirmos nos livrar de js
puros , teremos que resolver, de alguma forma, problemas de infraestrutura, nos livrarmos do código boilerlet etc. Em outras palavras, para fazer sua bicicleta um pouco ... Para não fazer isso, eu gostaria de levar algo em que tudo já foi feito e é de qualidade suficiente. Consequentemente, minha escolha recaiu sobre o
Polymer - uma estrutura do Google, que levou os componentes da web ao padrão.
Voltar para a montagem. Muitos de vocês (desenvolvedores Java, de qualquer forma) estão acostumados a uma ferramenta como maven e gradle, e você provavelmente descobriu que eles estão fazendo um ótimo trabalho com a manipulação de recursos (para maven, isso é um pouco pior, mas para gradle, não há problemas. qualquer coisa). A comunidade de front-end nos oferece o npm, para o qual nodeJs é necessário, mas isso não é suficiente, o webpack também está no topo. E eles ainda precisam entender e colocar para cada desenvolvedor. Hum ... Eu gostaria de desinflar o repositório, fazer o gradlew construir e começar a trabalhar, então vamos parar no gradle usual.
Obviamente, não podemos ficar sem o npm, pelo menos precisamos de um repositório de onde obter as bibliotecas js e o npm o fornece, mas o utilitário é opcional. Você pode encontrar algumas boas soluções como
essa , mas elas sempre baixam nodeJs e executam tarefas npm. Uma opção, mas gostaria de minimizar a comunicação com o npm antes de interagir com o repositório e muito mais. Como solução, escreva seu próprio plugin para gradle. Embora escrever plugins para gradle seja bastante simples, devido à grande variedade de opções para especificar versões para o repositório npm, a tarefa é um pouco mais complicada. Felizmente, existe uma
documentação clara para isso.
Então, vamos escrever um script gradle para carregar dependências. É usado pelo kotlin dsl pelo motivo de que a reescrita no groovy dsl é trivial o suficiente, mas, pelo contrário, levaria tempo se não houvesse experiência anterior.
repositories { mavenLocal() jcenter() } dependencies { classpath("com.github.artfable.gradle:gradle-npm-repository-plugin:0.0.3") } apply(plugin = "artfable.npm") configure<GradleNpmRepositoryExtension> { output = "$projectDir/src/libs/" dependencies = mapOf( Pair("@polymer/polymer", "3.0.5"), Pair("@polymer/app-layout", "3.0.1"), Pair("@polymer/paper-toolbar", "3.0.1"), Pair("@polymer/paper-icon-button", "3.0.1"), Pair("@polymer/iron-icons", "3.0.1"), Pair("@webcomponents/webcomponentsjs", "2.1.3") ) }
Este
plugin nos adicionará
npmLoad . Para deixar o grupo IDE bem, defina-o em um grupo
tasks["npmLoad"].group = "frontend"
Ótimo, você pode tentar escrever código para o nosso front-end. O servidor Intellij interno informará por padrão que o
Método Não Permitido está tentando conectar scripts via importação. Para evitar isso, marque a caixa de seleção
permitir o uso de solicitações . (nas últimas versões funciona sem ele).
Vamos tentar começar agora e ... Ainda assim, nada funcionou. As dependências dentro dos componentes do polímero caíram. O fato é que muitas bibliotecas js empurram importações com a expectativa de algum tipo de transpiler como o babel. Essa importação é assim:
import '@polymer/polymer/polymer-legacy.js';
Essa importação de sintaxe não está correta, pois para um navegador, o caminho deve começar apenas com '/', './' ou '../'. Além disso, desta forma, não pode ser tomado como relativo ou absoluto, pois aqui o cálculo é feito para o início do diretório da biblioteca a partir da raiz. Portanto, esses caminhos precisam ser corrigidos e, para não fazê-lo, você pode usar um
plug-in preparado.
De acordo com
classpath("com.github.artfable.gradle:gradle-js-import-fix-plugin:0.0.1")
apply(plugin = "artfable.js.import.fix") configure<GradleJsImportFixExtension> { directory = "$projectDir/src/libs" }
A tarefa
jsImportFix será
adicionada, o que trará todas as importações em ordem.
Assim, e sem ter que lidar com uma montanha de novas ferramentas, você pode montar uma frente. Mas vejamos a questão dos estilos novamente. Francamente, os componentes da web se livram do clichê, e as variáveis em css que já estão no padrão abrem muitas possibilidades, de modo que coisas como sass não são mais necessárias. Mas de repente, por exemplo, você gostou muito do
bootstrap e queria criar um design com base nele.
Encontrar qualquer plug-in para desenvolver esse assunto não é um problema, basicamente, todos eles tomam a
libsass como base e existe um wrapper em java -
jsass . O único problema para todos (pelo menos no momento em que eu os considerei) é duplicar arquivos dependentes.
Um exemplo:
Arquivo a:
@import “b”; @import “c”;
Arquivos _B e _c:
@import “d”;
Como resultado, obtemos no arquivo principal 2 blocos idênticos do arquivo _c. Você pode simplesmente corrigi-lo, se você adicionar o
importador ao jsass, a API permite. Na verdade, portanto, estou de novo com minha decisão
aqui (se não houver tais requisitos, é melhor usar outra solução).
Adicionar dependências npm à lista
Pair("bootstrap", "4.1.3")
Dependência de plug-in
classpath("com.github.artfable.gradle:gradle-sass-plugin:0.0.1")
apply(plugin = "artfable.sass") configure<GradleLibsassPluginExtension> { group(delegateClosureOf<GradleLibsassPluginGroup> { sourceDir = "src/sass" outputDir = "src/css" } as Closure<Any>) } tasks.create("processResources")
A tarefa falsa processResources
terá que ser criada se o plugin java não estiver conectado (e não precisamos dele aqui). Claro que isso é uma falha, então eu definitivamente vou consertar.
Observe que o arquivo css resultante não deve estar conectado ao
cabeçalho , pois, dentro do componente, ele não estará visível, mas diretamente no modelo do próprio componente.
A última etapa é modificar levemente o script para obter o diretório de
compilação usual, com um projeto pronto que pode ser implantado no prod.
O código completo foi carregado no github (você provavelmente terá que migrar para o gitlab mais tarde ...).
Espero que a idéia básica seja clara e você possa adicionar simplesmente o que quiser. Obrigado pela leitura.