Archive for the ‘web’ Category

Separation of concerns (SoC) – Front-end – 4 Layers

Separation of concerns (Separação de conceitos) apesar de não ser algo novo, ainda pode dar muita dar de cabeça.
Pensando nisso que resolvi escrever um cado sobre e compartilhar como vejo as coisas no front,
principalmente nesse momento em que o frontend passa por um turbilhão de coisas novas…

Como disse antes, talvez você não veja nada de novo, e até vai achar meio tosco =P.
Compreenda que o intuito não foi gastar tempo escrevendo um cenário mais aprazível, também não focarei no passo a passo das coisas, ou seja, não farei deste post um tutorial, ok? 😉
#simbora

 

Separation of concerns – Design Principle

Acoplamento: o grau de dependência entre dois módulos.

Coesão funcional: A coesão funcional é quando partes de um módulo são agrupadas porque todas elas contribuem para uma única tarefa bem definida do módulo.

Manutenção: uma medida de como é fácil manter o sistema.

Extensibilidade: uma medida de quão facilmente o sistema pode ser estendido com novas funcionalidades.

Reusabilidade: uma medida de como é fácil reutilizar um módulo em um sistema diferente.

Essa versão resumida de SoC é o que vamos ter em mente nas nossas alterações.

 

Nosso caso:

Como a arquitetura está nesse ponto:

(View+Model+Controller sem muita definição sobre suas responsabilidades)

(View+Model+Controller sem muita definição sobre suas responsabilidades)


STYLE

Iniciarei pela parte que está mais batida (assim eu espero)
Nosso querido style!
Facilmente se encontra bons conteúdos sobre esse assunto.
E tanto faz aqui o que você tem como apoio OOCSS, ACSS, BEM, SMACSS ou outro….
O importante, pra mim, é não deixar o style no DOM.
Jogue para um arquivo (de preferência um sass lindão, ou, claro,
se a tecnologia já tem sua maneira de lidar com isso, como é o caso do VUE, use-a!)

Particularmente prefiro simplificar algumas coisas aqui.

  1. pai-filho-característica costuma resolver todos os meus problemas
  2. Nível de indentação maior que 4 pode embolar as coisas
  3. Não use !important
  4. Tem que ser fácil customizar o elemento dependendo do seu contexto


TEMPLATE

Indo para o template:
Também não tem mistérios, mas tem DEV que insisti em fazer o !melhor possível aqui =/
Trabalhando um pouco mais no nosso template ele vai ficar assim:

Acabamos de deixar o style da nossa view pra quem sabe dessas coisas e a manipulação pro código,
assim nossa view começa a ver uma luz …
(Voltaremos na view depois)


CODE

Agora é a vez da estrela, o código!
Quem vai ficar por fazer a manipulação de dados e etc…
No início nosso código estava assim:

Depois de um update ficou assim:

Internalizamos a funcionalidade/operação que estava no DOM…
Agora garantimos que cada camada esteja fazendo o que lhe cabe…

CSS -> Pra estilo
Html -> Exibe o dado seguindo o estilo.
TS -> Pra inputar informação na view

(View-Model-Controller com suas responsabilidades mas bem definidas)

(View-Model-Controller com suas responsabilidades mas bem definidas)


 

Até aqui, ok?
Podemos chamar esse parte de primeiro ciclo.
Vamos para o segundo, tudo de novo, só que, agora, iniciando pelo código.


CODE

Voltando pra programação:
Vamos analisar o código com um olhar mais critico, e,
com pouco esforço, já vamos notar que esse controller faz muita coisa. Ruim.

Não é difícil ver desenvolvedor pimpão usando 3 camadas (MVC, MVP ou qualquer outra sopa dessas) e estrangulado/sobrecarregando as camadas.
Foco no concerne!
Tente subir o máximo possível o nível das responsabilidades do seu código.
O que somente o controller, ou qualquer outra camada que fique perto da view, deveria fazer?

Buscar dado?!  Será?
Prefira delegar isso pra outra parte.
Parte que vai cuidar dos dados da view.

Manipular dados? Será?
Deixe isso também pra camada que vai cuidar dos dados.

Uai! Então o que o controller faz?
Só o que só ele pode fazer =)
Ele é o único próximo o suficiente da view pra ouvir seus eventos e inputar dados.

Novo controller:

Transferindo o que estava n@ controller para nossa nova camada teremos:

Vamos centralizar qualquer dependência de dado da view nessa camada, qualquer eventual formatação e etc.
Entretanto, nossa nova camada ainda vai direto na API para buscar o dado, e é isso que vamos remover.

Pronto!
Onde tinhamos -> View + model + controller

Agora temos -> View + model + controller + data-layer -> APIs

 

E no final ficou assim:

 

Ainda temos muito pra trabalhar nesse pequeno caso, não chegamos a terminar o segundo ciclo, não chegamos nem a listar os impactos das mudanças nos nossos testes de unidade, não componentizamos e etc =)
Essas coisas legais ficarão para um part2 desse post 😉

Abraços!

Angular 2 – Bundle

Angular 2 trouxe muitas coisas legais, mas algumas coisas NÃO tem sido fácil =’/
Uma dessas coisas ruins que estou enfrentando com Angular 2 tem sido gerar um bundle pra produção num fluxo fluido de trabalho…
Pensando nisso (sofrendo com)…
Resolvi fazer uns protótipos com diversas ferramentas pra saber o caso de uso de cada uma delas.

 

Webpack

(work in progress)
https://github.com/Espigah/JavascriptRepo/tree/master/Angular2/casework_6_bundle/webpack

JSPM + SystemJS

(work in progress)
https://github.com/Espigah/JavascriptRepo/tree/master/Angular2/casework_6_bundle/jspm

Rollup

(work in progress)
https://github.com/Espigah/JavascriptRepo/tree/master/Angular2/casework_6_bundle/rollup

Angular “official”

(work in progress)
https://github.com/Espigah/JavascriptRepo/tree/master/Angular2/casework_6_bundle/official

Gradle

Coming soon…
https://github.com/Espigah/JavascriptRepo/tree/master/Angular2/casework_6_bundle/gulp

Gulp

(Coming soon) https://github.com/Espigah/JavascriptRepo/tree/master/Angular2/casework_6_bundle/gradle

 

 

%d blogueiros gostam disto: