Sobre lógica de programação no meio do código HTML #505
Replies: 11 comments
-
|
Então @woliveiras como estávamos conversando, é meio que uma guerra entre imperativo e declarativo. A grande maioria dos devs fica mais confortável com declarativo do que no imperativo. Parte desse conforto é devido a familiaridade que templates (declarativo) tem com o html final, outra parte talvez seja devido a baixa capacidade de abstração que tenho visto em muitos devs, porém isso é mais especulativo da minha parte. Sejamos francos, template é mais tranquilo de se ler do que render function <div>
<h1>{{ title }} </h1>
<p v-for="(content, index) in paragraphs"
:class="{ odd: (index % 2) === 0}">
{{ content }}
</p>
<div>/// compiled version
function render() {
with(this) {
return _c('div', [_c('h1', [_v(_s(title) + " ")]), _l((paragraphs), function(content, index) {
return _c('p', {
class: {
odd: (index % 2) === 0
}
}, [_v(" " + _s(content))])
}), _c('div')], 2)
}
}// JSX
<div>
<h1>{this.title}</h1>
{this.paragraphs.map((content, index) => {
(<p className={((index % 0) === 0) ? 'odd' : null }>
{content}
</p>)
})}
</div>// pure render function
// https://jsfiddle.net/jmy9Lqm4/
render (h) {
return h('div', [
h('h1', this.title),
...this.paragraphs.map((content, index) => h('p', {
class: {
odd: (index % 2) === 0
}
}, content))
])
}O primeiro snipet é um fragmento de template vue, o segundo é como ela fica compilada, o terceiro é a versão JSX, o quarto é uma render function feita do zero, sem nenhuma compilação. Mesmo eu usando ES2015 para diminuir o boilerlate de código e facilitar a leitura, ainda vão haver devs que podem nem conseguir entender o que esta acontecendo no terceiro exemplo. Um pouco de contextoVue.js assim como React usa v-dom, ao usar v-dom basicamente passa a ser mandatório o uso de render functions. A sintaxe de template do Vue.js é compilada (em tempo de execução ou em tempo de compilação) em render functions, ou seja, o "html vira js" Diferente do que havia com Angular 1 e Vue 1, onde a template passava por um parse e nela eram atribuídos comportamentos. Entre outras coisas, um dos problemas disso no NG1 eram os erros silenciosos (um erro de sintaxe ou lógica que passava perspetivável ao projeto). Esse tipo de erro não acontece, pois oque esta sendo executado é código JavaScript, que vai estourar erro caso algo assim acontece. É senso comum que render functions (imperativo) é mais poderoso e flexível se comparado a templates (declarativo), o fato de não serem "simples" de se ler é até um fator positivo, que impede que componentes "grandes" sejam criados facilmente. O problema acontece quando a API para a criação dessas render functions muda por algum motivo, além do problema de leitura, que essas funções podem ter, mesmo que uma parcela de devs não se incomode com, este é um problema real. Pensando nisso que JSX foi projetado, ele é meio que o "melhor dos dois mundos". Ele é uma especificação que permite que as APIs da render functions sejam modificadas e o código em si continue o mesmo ou com pouquíssimas alterações. Melhor dos dois mundos pois ele aceita código JavaScript para suas "operações lógicas". Porém ainda há uma parcela significativa de devs que não se adapta com o JSX, e ainda prefere templates. É uma questão quase infinita, porém o que me conforta é o poder e escolha, existem 3 opções no Vue.js e 2 no React. Se for comparar JSX e templates (no contexto Vue.js e react) cumprem o mesmo proposito: facilitar a escrita e leitura e diminuir o impacto de mudanças na API das render functions. O @woliveiras havia me perguntado se usar JSX no Vue.js seria "ir contra a comunidade". Eu não diria "ir contra a comunidade", porém o uso de JSX é bastante baixo na comunidade Vue.js, para fins práticos não existe nenhum impacto em usar ou não JSX, pois o resultado compilado é basicamente o mesmo que usar templates. Porém, em uma equipe, inevitavelmente será mais fácil para novos membros se adaptarem a template do que JSX. Não que isso seja um grande impacto, mas ainda será uma adaptação extra. Escrevi bastante 😥 espero ter atendido a duvida. |
Beta Was this translation helpful? Give feedback.
-
|
Implementar lógica de forma declarativa é mais fácil e simples para os outros entenderem (principal motivo do boom das antigas template engines e o angular 1). Não encare como um antipadrao desde que você mantenha coesão em seus componentes. |
Beta Was this translation helpful? Give feedback.
-
|
Como nunca li muito a respeito, vou fazer uma análise mais prática baseada nas minhas próprias experiências ao usar certos frameworks. Tive a oportunidade de trabalhar em alguns projetos pessoais com Riot.js (que se parece muito com o Vue.js) e em outro projeto usei o Inferno.js (que usa JSX, sintaxe do React). Posso afirmar sem medo que prefiro mil vezes trabalhar de forma declarativa nos componentes e views, do que de forma mais programatica como no React (ou em outros frameworks). A forma declarativa permite uma velocidade absurda na hora de montar views e componentes. É algo natural, flui rápido, e se feito seguindo um padrão (e sem gambiarras, enfiando muito código nos atributos) fica extremamente simples e organizado. Você pode ver um exemplo de como dá pra montar um projetinho com pouquíssimas linhas de código trabalhando com frameworks declarativos nesse meu projeto (da uma olhada na pasta Hoje em dia se eu pudesse escolher as tecnologias de qualquer projeto com que eu mexo, frameworks declarativos como Riot e Vue estariam definitivamente no topo da lista. Tanto pela produtividade, quanto pela facilidade de usar. |
Beta Was this translation helpful? Give feedback.
-
|
Quanto mais escrever, melhor, @vinicius73 kkkkk |
Beta Was this translation helpful? Give feedback.
-
|
Então eu entendi certo nas pesquisas e a vantagem é por facilitar o entendimento do código, né? |
Beta Was this translation helpful? Give feedback.
-
|
Isso, leitura e manutenção, já que a API da template/JSX dificilmente quebra. |
Beta Was this translation helpful? Give feedback.
-
|
Vou ponderar sobre os pontos com os quais acho que posso contribuir
É preciso separar o que é lógica de interface e lógica de modelo. Quando eu uso as marcações para modificar a estrutura da página estou apenas mapeando estados da aplicação. Isso é descartável e tem como objetivo apenas informar o usuário sobre os estados da minha aplicação. Sendo assim não estou dispondo minha lógica, mas representando estados.
Eu as vejo como um ponto altamente positivo. Não sei se você teve a oportunidade de lidar com projetos onde não há nenhuma ferramenta ajudando a sua tela a manter estados. Quando isso acontece, por conta da falta de estado do http, você precisaria reenviar tudo o que estava sendo feito no momento para conseguir uma visão do novo estado provido pelo servidor (ex.: quando um select de estado recarrega a página para listar as cidades). Mapear estados na interface faz-se necessário na programação desde os primórdios quando o cursor do terminal começou a piscar para indicar que você poderia digitar novos comandos : )
Creio que o que você possa estudar para isso são os conceitos do ViewModel, que é basicamente uma psedo-camada do seu View.
Não deveria causar qualquer efeito colateral, haja visto que para este tipo de ferramenta o que é possível testar é se os estados da aplicação estão corretamente representados pela interface : )
Como apresentado mais acima se você tiver lógica de negócio embutida de verdade no seu template você tem um problema, do contrário é natural. Vou dar uma exemplo. Vamos pegar um TodoApp. Nesse tipo de aplicação você tem um modelo lógico simples: tarefas que podem estar definidas como prontas ou a serem feitas. Sua lógica de negócio, provavelmente o seu back-end, tem a habilidade de gerenciar e armazenar esse estado. Contudo a sua interface tem que prover informações significativas para representar isso. Se eu fizer um teste no meu template sobre o estado do Todo e modificar a forma de apresentação dele eu não mudei a lógica de nada: eu apenas representei o estado. Espero ter contribuído em alguma coisa com a dúvida ; ) |
Beta Was this translation helpful? Give feedback.
-
|
Contribuiu demais @wilcorrea 🤘 🤘 🤘 |
Beta Was this translation helpful? Give feedback.
-
|
Só uma contribuição rápida:
Com React você tem a view (HTML) no JS. Considerando "boas práticas", isso é muito pior que a outra situação (lógica na view). Inclusive a divulgação do React foi feita com base no Rethinking best practices. Sobre a sua pergunta:
Um ponto positivo de lógica no template é que você diminui bastante as camadas de abstração do projeto. Quando você cria um novo componente, e usa uma tag para chamá-lo Isso é um downside da cultura de componentização que está presente em todos os principais frameworks/libs JS atualmente (React, Angular 1 e 2, Ember, Vue, etc). Se o componente não for ser reutilizado de fato, você está aumentando a complexidade do projeto sem necessidade. A escolha da ferramenta vai realmente depender muito do projeto. Para sistemas CRUD, com bastante form, Angular 1 é muito simples e efetivo. Creio que se a galera tivesse investido em adicionar um sistema de VDOM na API do Angular 1, Vue e React não teriam ganhado tanta atenção/tração. Por que? Porque React é complexo de se juntar todas as partes, não se tem uma padronização de projetos, e ai você tem que ir testando várias arquiteturas até chegar em uma que você se sinta confortável. Como a única coisa que você pode construir em React são componentes, se não for um projeto que tenha sido bem pensado/projetado, com um UI-Kit definido previamente, o projeto vai ficar muito mais confuso/complexo para dar manutenção, fazer onboarding de novos devs é bem mais difícil, etc. Ou seja, é uma ferramenta que necessita de uma boa estrutura da empresa para sua adoção, com um designer bom para criação do ui-kit, um desenvolvedor com uma certa experiência para criação da arquitetura e uma cultura boa em relação a equipe para levar o projeto para um paradigma mais funcional. Porque Vue tem um sistema de diretivas pior que o do Angular 1, e a forma como você tem que escrever seu JS tem bem mais "regras" que o NG1. Fiz um POC usando Vue2 e no fim o que senti foi isso, tem menos coisas que o Angular 1, com mais boilerplate, e pelo fato da comunidade ser menor, tem menos "plugins" disponíveis. |
Beta Was this translation helpful? Give feedback.
-
|
Tirando as colocações sobre o VueJS eu concordo com o @ericdouglas 🤣 🤣 🤣 🤣 🤣 |
Beta Was this translation helpful? Give feedback.
-
|
Excelentes pontos, @ericdouglas |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Fala galera!
Não consegui pensar num título melhor pra essa issue por que não sei exatamente se isso é um problema, então eis a minha questão:
Atualmente trabalho com Angular 1 e estou pensando em praticar algum framework moderno.
Fui procurar as opções e parei nesses dois: Vue.js e React.
Ambos possuem ótimos pontos a favor e o @vinicius73 me deu bons insights sobre Vue, mas meu problema não é bem qual dos dois escolher... Uma coisa me incomoda no Vue: a lógica no meio do HTML e que eu tanto reclamo no Angular 1 (ng-if, ng-repeat, v-if, v-for).
Eu gostaria de entender o por que essas funcionalidades são boas para uma aplicação JS. - ou o por que não seriam.
Não sei se pesquisei errado, mas não achei nenhum artigo maneiro explicando o por que disso ser bom para a aplicação a não ser que fica mais fácil para ler para algumas pessoas.
Por exemplo: não achei se isso ajuda em testes, se isso é bom para performance ou coisa do tipo.
Pra mim isso parece ser um anti-pattern pois temos lógica na view (sendo o HTML nossa view).
Beta Was this translation helpful? Give feedback.
All reactions