DEV Community: Edvaldo Lima

Front-End e o gerenciamento de estado global

Edvaldo Lima — Fri, 04 Aug 2023 14:12:59 +0000

As bibliotecas Flux são como óculos: você saberá quando precisar delas. Dan Abramov, o autor do Redux.

E aí carinha do computador. Como que anda a vista? E os óculos? Tudo em dia?

Eita, o gerenciamento de estado global! Já ouvi falar muita coisa sobre ele:

"Você só usa quando precisa passar dados de irmão para irmão(componentes) para facilitar a vida"
"Só usa quando a hierarquia entre os componentes fica muito distante"

Vamos cortar o papo, do que é, onde vive, do que se alimenta, etc. E vamos focar no propósito de existência do gerenciamento de estado global em um projeto.

Veja:

fonte

Antes de qualquer coisa, vamos falar do Vuex, mas isso pode se aplicar as bibliotecas que fazem uso do Flux Pattern, para aquele seu projeto de 5 páginas, ou qualquer coisa nesse sentido, provavelmente não fará sentido algum adicionar gerenciamento de estado global, inclusive, é uma recomendação do Vuex, Redux.

Se o seu projeto consome uma API, ele já poderia fazer o uso do gerenciamento de estado global! "Mas pera, e a história do projeto de 5 páginas?", é simplesmente uma escolha! Deve se considerar os prós e contras do uso em seu projeto.

Mas vamos ao propósito, viu a imagem ali em cima e o que cada camada faz? Vamos lá!

Actions: A camada que tem como responsabilidade a comunicação com a API do projeto.
Mutations: A camada que tem como responsabilidade modificar estados.
Getters: A camada que tem como responsabilidade facilitar a busca dos dados de um estado.
State: A camada que tem como responsabilidade armazenar o estado.

Com o gerenciamento de estado global, a aplicação irá centralizar os dados vindos da API no State fazendo com que qualquer componente tenha acesso aos dados, da mesma forma as chamadas de API ficam ao alcance de qualquer componente por meio do Vuex, como à qualquer outra camada, e sim, as Actions seriam um tipo de "Services", centralizando todas as chamadas de API. Claro, você não irá guardar apenas os dados vindos da API, poderá adicionar qualquer dado de interesse global ou de contexto.

Conclusão

Para pequenos projetos, mesmo com consumo de API, o gerenciamento de estado global pode parecer verboso e desanimador, mas na minha opinião o uso se paga e muito bem ao longo do projeto, você sabe de onde vem os dados, são modificados de forma previsível e isso ajuda muito na manutenção.

CapacitorJS, PWAs e como empacotar um front-end para Android e iOS.

Edvaldo Lima — Thu, 01 Jun 2023 11:00:39 +0000

🛠️ Por que usar Capacitor em vez de só uma PWA

Você desenvolve aplicações web (HTML, CSS, JavaScript) e ficou interessado em levar esse mesmo código para dispositivos móveis, transformar sua PWA em binários instaláveis (.apk para Android e .ipa para iOS) é uma possibilidade real com o CapacitorJS — uma runtime nativa criada pela equipe do Ionic que funciona como evolução moderna do Cordova.

🧠 O que é o CapacitorJS

O CapacitorJS é um runtime nativo open-source que permite empacotar aplicações web como apps nativos para Android, iOS e também servir como Progressive Web App (PWA). Ele fornece uma bridge entre o código web e APIs nativas (como câmera, GPS, notificações, armazenamento nativo, etc.), com uma API consistente que funciona tanto no contexto web quanto nas plataformas móveis.

Diferente do Cordova, o Capacitor foi projetado para ser mais modular, trabalhar com plugins modernos e ter melhor integração com APIs e ferramentas nativas atuais. Progressive Web Apps já oferecem uma experiência rica em navegadores modernos, com recursos como service workers e instalação no dispositivo.

Mas se seu objetivo é:

Publicar na Google Play Store e Apple App Store;
Usar recursos nativos do dispositivo com performance mais integrada;
Ter um binário nativo que não dependa exclusivamente do navegador do usuário;

… então o Capacitor é uma solução técnica mais robusta do que apenas uma PWA comum.

🚀 Como empacotar seu front-end com Capacitor

Instalação da CLI e Core

Instale o capacitor no seu projeto:

npm install @capacitor/core
npm install -D @capacitor/cli

Inicialização do projeto

npx cap init

Isso cria os arquivos de configuração básicos.

O capacitor.config.ts

Esse arquivo define parâmetros essenciais, como o appId, o nome do aplicativo e o diretório onde o build web será gerado (geralmente dist):

import { CapacitorConfig } from '@capacitor/cli'

const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'local-chat',
  webDir: 'dist', // destino da build do seu projeto
  server: {
    androidScheme: 'https'
  }
}

export default config

Adicionando plataformas

Depois da configuração:

npm install @capacitor/android @capacitor/ios
npx cap add android
npx cap add ios

Build e sincronização

Construa seu front-end com seu framework (React, Vue, Svelte, etc.):

npm run build

Em seguida sincronize com o projeto nativo:

npx cap sync

Abrir nos IDEs nativos

Por fim, abra o projeto no Android Studio ou Xcode:

npx cap open android
npx cap open ios

Ou execute direto no dispositivo (se a configuração estiver correta):

npx cap run android

Esse fluxo já te permite instalar e testar o app no dispositivo.

📌 Considerações finais

O desenvolvimento híbrido com Capacitor é uma alternativa eficiente para muitos projetos onde manter uma única base de código é uma vantagem (Web + Android + iOS). Em muitos casos você consegue acessar APIs nativas sem escrever Swift/Kotlin — mas se precisar de funcionalidades nativas personalizadas, plugins ou código específico ainda podem ser escritos e integrados.

O uso de Capacitor não exclui a necessidade de entender os ciclos de build nativos quando for necessário ajustar elementos específicos — mas para a maioria dos cenários padrão, a experiência é bastante fluida para desenvolvedores web.

Front-End, o mundo além de pintar botões.

Edvaldo Lima — Thu, 25 May 2023 11:31:02 +0000

E aí programador, cê ainda sobe uns projetos por FTP em pleno 2023? Fica tranquilo, acontece nas "melhores" empresas. 🤭

Se você aí é programador das antigas, por um acaso bateu a cabeça e ficou em coma por uns 15 anos, acordou e acha que JQuery ainda é tech de ponta e que front-end ainda é aquela "simplicidade", estamos todos enganados!

A piadinha do programador, na verdade, pode ser eu e você, sabemos que o JQuery não é tech de ponta, mas a ideia de que o front-end é algo "extremamente simples", ainda perdura pelos dias de hoje nas nossas cabeças, me lembro da primeira vez em que li "Front-End Engineer", achei exagerado, pensei, "quer dizer que o cara vai assinar um papel e se o front cair em produção, será responsabilizado por todos os danos"(parecido com o que acontece na engenharia civil quando cai uma ponte), sentei, passei uns dias entendendo e me dei conta de que ainda não estava levando o assunto a sério.

Já faz um bom tempo que as necessidades do front-end mudaram, e foram mudanças rápidas e que mudaram totalmente a forma de desenvolver e de pensar, logo apareceram coisas como:

SPA(Single Page Applications)
PWA(Progressive Web App)
Offline First
Componente
Arquitetura
Roteamento
Otimização de desempenho
Análise minuciosa de novos pacotes adicionados ao projeto
Atualização dependências
…

Não tem como estruturar um bom projeto com a "cabeça do JQuery"! Esse pensamento de que "é tudo muito simples", "só seguir e vai dar tudo certo", de forma resumida, isso pode resultar em projetos complexos de manter e dar manutenção ao longo do tempo.

Eu vivi algo que me trouxe um grande aprendizado, na época eu já tinha trabalhado com back-end, mobile e front-end, sai de uma empresa e fui para outra, e a minha ideia era começar uma jornada apenas com o front-end, nessa outra empresa eu ainda estava colocando a mão em back-end, ao passar dos dias eu fui conhecendo o projeto e entendendo melhor, era VueJs e Laravel, porém, o time estava migrando do VueJs para o Svelte, em um momento em que o Svelte nem sequer estava consolidado, ao tentar entender melhor, recebi uma explicação parecida com isso: "há, acontece que com o VueJs ficou muito complicado de dar manutenção no projeto", e eu ainda fico por ali sem entender a explicação sabendo que o projeto nem sequer tinha 2 anos de existência, no final eu entendi que o front-end foi negligenciado no que diz respeito a sua complexidade e que mudar de seis(VueJs) para meia dúzia(Svelte) não iria adiantar em nada, se mantido o mesmo pensamento "simplista".

Chegar ao ponto de migrar/reescrever um projeto com uma justificativa fraca é o resultado de escolhas ruins no início e ao longo do projeto, não se pode se dar ao luxo de reescrever, sabemos que isso envolve custos, por isso, estruturar um bom projeto e manter boas práticas é essencial para o sucesso do projeto ao longo do tempo, um projeto de simples entendimento e manutenção.

Conclusão

A ideia aqui está longe de querer hipervalorizar algo, apenas dar um pitaco sobre um assunto que muitas pessoas ainda tratam de maneira simplista, entender as necessidades atuais e aplicar aos projetos pode nos livrar de longas dores de cabeça.

Component vs View.

Edvaldo Lima — Fri, 19 May 2023 14:00:11 +0000

E aê Frontender, debugando muito código com console.log(❤️)?

No meu primeiro post aqui, venho falar sobre mais uma das dificuldades para nós, programadores, assim como dar bons nomes às nossas variáveis com significado e contexto, pode ser algo que leva tempo, os componentes e as views em um projeto front-end se encaixam muito bem nessa mesma situação, no sentido dos seus propósitos no projeto.

Você não precisa ir muito longe para encontrar projetos com componentes de umas 1000 linhas de código e cheios de regras mirabolantes que vão se comportar dependendo do que tu passa pelas propriedades ou dentro do componente.

Sobre componentes, na doc do Vue:

Os componentes nos permitem dividir a interface do usuário em peças independentes e reutilizáveis e pensar em cada peça isoladamente. Components Basics

Componentes de contexto

Se no seu projeto tem vários componentes que fazem algo parecido com isso:

[...]
if(isUser){
  await fetchUser()
} else {
  await fetchCompany()
}
[...]

Temos então, componentes de contexto, componentes dependentes de que a lógica de alguma forma diga se é um usuário comum ou empresa, logo, ele não é um componente independente.

Temos daí, dois contextos, o contexto de usuário e o de empresa, onde o ideal seria criar componentes que tenham contexto único, exemplo:

<!-- User Info -->
<UserInfo />
await fetchUser()

<!-- Company Info -->
<CompanyInfo />
await fetchCompany()

<!-- In view -->
[...]
<component :is="userOrCompany" />

if(isUser){
  this.userOrCompany = UserInfo
} else {
  this.userOrCompany = CompanyInfo
}
[...]

Componentes genéricos, independentes

Os componentes independentes de contexto, geralmente cumprem um único papel, não dependem de lógica contextualizada para existirem, exemplo:

<!-- SInput -->
<SInput />

<!-- Inside -->
[...]
<input :type="inputType" />

props:{
 inputType:{
  type: String,
  default: () => 'text',
 }
}
[...]

Por default no html os inputs sem a propriedade type, são do tipo texto, nem precisaria do default na propriedade do vue, mas o fato é que, esse componente consegue simplesmente existir sem precisar que alguma lógica diga para ele, de como ele deve se apresentar.

Componentes reutilizáveis

Eu particularmente já encontrei algo bem parecido com isso:

<ModalNewUser />
<ModalNewSettings />
<ModalNewCity />

Mas não tem nada de errado nisso, correto? Deixa explicar, os componentes modais tinham exatamente replicados os mesmos comportamentos de uma modal, de forma simples, todos tinham, title, body e actions.

O problema:

<!-- ModalNewUser -->
<div class="modal">
  <div class="title">
    Add New User
  </div>
  <div class="body">
    <!-- form -->
  </div>
  <div class="actions">
    <button>cancel</button>
    <button>add</button>
  </div>
</div>
[...]

<!-- ModalNewSettings -->
<div class="modal">
  <div class="title">
    Add New Settings
  </div>
  <div class="body">
    <!-- form -->
  </div>
  <div class="actions">
    <button>cancel</button>
    <button>add</button>
  </div>
</div>
[...]

<!-- Etc -->

Uma possível solução, para reutilização:

<!-- SModal -->
<SModal />

<!-- Inside -->
<div class="modal">
  <div class="title">
    <slot name="title"> {{ title }} </slot>
  </div>
  <div class="body">
    <slot name="body"> {{ body }} </slot>
  </div>
  <div class="actions">
    <slot name="actions">
      <button>cancel</button>
      <button>add</button>
    </slot>
  </div>
</div>

props:{
  title: {
   type: String,
   default: () => 'Confirm action?',
  },
  body: {
   type: String,
   default: () => 'Click, to confirm action',
  }
}

O código resumido do componente a cima, mostrar duas formas de customizar um componente sem replicar código comportamental próprio da modal, se pode simplesmente mudar o texto do título e corpo por propriedades, ou, por slots caso no corpo da modal se adicione um formulário ou algo do tipo.

Componente isolado

Por si só um componente é um trecho de código isolado, seja ele aplicado à um contexto ou um componente genérico, o importante, no caso de componentes contextualizados, é isolar por contexto dando ao componente uma única responsabilidade no projeto.

Conclusão

Você deve ter notado, que o foco maior foi nos Components, porque na realidade a View é quem vai encapsular todo o resto, é um pouco mais complexo que isso, é verdade, temos que ter cuidado em sempre isolar o máximo de código a fim de evitar muita lógica condicional na View tornando a manutenção complexa.