A maioria das empresas, principalmente no Brasil como podemos observar, utilizam o Redux como gerenciador do estado dos dados da aplicação.

Se você vai trabalhar com React, vai se deparar com ele em algum momento. Chegam muitos testemunhos de que o React é fácil, mas o Redux ainda é um entrave.

Mudança de Mindset

Utilizar as melhores práticas com o Redux requer pensar de forma imutável e funcional com uma biblioteca e linguagem multi-paradigma, além disso a própria documentação do Redux não facilita, ela é pra quem já tem esse Mindset e confunde mais do que ajuda.

Vamos pensar apenas em React

Acredito que uma forma de entender um motor de estados é entender qual o problema que ele resolve primeiro, depois como ele funciona, para isso proponho nesse Workshop resolver essa compreensão puramente com React, lib da qual todo mundo me fala que entende fácil e é logo produtivo.

Workshop Construindo seu próprio Redux

Construiremos um Centralized State Management baseado no Pattern Flux fortemente inspirado no Redux. Pré-requisito é entender um pouco de React, mas nada que numa manhã não aprenda, de qualquer forma revisitaremos alguns conceitos de funcionamento da árvore.

Todo o código já está disponível caso queira se aventurar sozinho nesse repositório, só acompanhar os commits https://github.com/cmilfont/learn-redux/commits/master. Provavelmente eu inclua mais algum detalhe até lá, revisite sempre.

Qual o investimento?

Apenas 200 reais, que você pode se inscrever aqui nesse link. [no futuro teremos uma versão bitcoin ;)]

[update] O Workshop já aconteceu e você pode adquirir os vídeos das aulas comprando no link anterior, mas não temos mais canal no slack pra novos participantes dessa turma.

Quando vai ocorrer?

Primeira turma será nos dias 15, 16, 17 e 18 de janeiro de 2018 iniciando todos esses dias as 19h até por volta de 21:00.

Formato online?

Utilizaremos o https://zoom.us/ para as aulas, os vídeos será disponibilizados para os inscritos após o curso.

Conteúdo

1. Implementando acesso a dados no ciclo de vida da árvore React
2. Utilizando banco de dados locais (IndexedDB) como fonte de dados
3. Diferença entre props e state para manipular os dados
4. Refatorando a centralização do estado de uma árvore
5. Utilizando Context para conectar os componentes na árvore a uma mesma fonte
6. Construindo o seu Redux: Store como provider do estado.
7. Construindo o seu Redux: padronizando dispatch de ações.
8. Isolando os componentes com Containers conectados ao Store
9. Mapeando trechos do estado para as Views.

Próximos Workshops

Esse daqui servirá como pre-requisito a Workshops de Redux e Saga que serão disponibilizados em breve.

Esse post é uma compilação de experiências de 2017 (e nos últimos anos pra falar a verdade) como um guia de recomendações para o foco em 2018. Analisando as respostas do “State of JS” para validar nosso Feeling com dados.

Linguagem

Javascript se tornou uma linguagem madura com um ecossistema rico de recursos auxiliares que a tornam presente no servidor, navegador e no seu celular.

Babel se tornou um padrão de fato para termos sempre as últimas novidades do JS, Typescript retornando com sucesso vencendo a concorrência contra o Flow e Webpack como Module Bundler tem aos poucos tornado obsoleto os anteriores (Grunt, Browserify e Gulp).

Indiferente da disputa histórica entre tipos dinâmicos e tipos estáticos, uma recomendação é sobre o pensamento imutável com Immutablejs.

Design Patterns

Domain Driven Design e outras coletâneas consagradas de padrões estão entrando na estante de livros do desenvolvedor Front agora com a maturidade do ecossistema e os Micro-frontends se tornando possíveis com algumas tecnologias como Import Async, seja utilizando o Webpack ou diretamente do Babel.

Sempre existiu uma grande necessidade do mercado em conservar código legado em vez de sempre reescrever tudo e agora a tecnologia nos permite uma evolução mais suave de como fazer isso.

Eu e a Kete Martins Rufino apresentamos “Transformando um front-end legado em uma React SPA” no ReactConfBR em outubro que traça algumas dicas e abordagens de como realizar essa evolução.

Frameworks

Falando em React, junto com Vue são as abordagens mais indicadas para focar em 2018 devido a sua recepção e crescimento aliado a esse pensamento de construção em blocos na evolução de legados em vez de um Framework de propósito geral que tenta resolver tudo. Óbvio que a escolha de um ecossistema envolve diversos aspectos, inclusive opinião pessoal.

Ouça o Hispters.tech sobre React que tentamos explicar um mundo de coisas sem código.

Algumas tecnologias como Reason, Elm e Clojurescript são interessantes, mas a realidade é que são relevantes apenas se você tem interesse especificamente em algumas poucas empresas que as utilizam.

Redux e Vuex

Se você abrir a lista de empresas que usam React ou Vue no BR e fizer um search vai perceber que praticamente 99,99% delas usam Redux e Vuex respectivamentes, que são um Centralized State Management.

Em outras palavras isso significa isolar o código que transforma e manipula seus dados para evitar acoplar nas suas Views tornando a manutenção e evolução bem mais robusta pela organização dessa abordagem.

Em composição a esse Mindset de coesão e baixo acoplamento também é recomendado um Middleware/Plugin que manipula chamadas assíncronas chamado de Saga, seja Redux ou Vuex, para evitar código dentro das Views.

Um Centralized State Management ainda facilita o Track e monitoramento de errors para PWA.

Progressive Web App

PWA não é uma tecnologia, é uma abordagem para construir Mobile Apps com os padrões WEB. No artigo “Progressive Web Apps: a palavra-chave é Progressive, não App ou Web” tem links, audio, video e slides sobre o tema.

Uma série de Apps já tem sua versão PWA: Twitter, Telegram, Instagram, Uber, Pinterest,… até o Tinder.

Middlewares

Com o lançamento do AWS AppSync agora no último re:Invent o GraphQL demonstrou que chamou a atenção e veio se consolidar como o Backend para o Frontend daqui pra frente.

É possível que Firebase, serverless campeão da atualidade, venha a oferecer GraphQL em breve.

Indiferente se você deseja continuar especialista em Front ou ganhar proeficiência no Backend pra se tornar um Full Stack, não vai poder ignorar Elasticsearch.

Esse motor de buscas é mais que uma DSL, hoje um mecanismo importante no Mindset imutável de construção dos seus Data Transfer Objects junto de Centralized State Management.

Automatizado

Por fim e não menos importante, um Front-end moderno não pode deixar de ser totalmente automatizado, desde o boilerplate gerador de build como o create-react-app, passando pelo Pipeline de CI com Jenkins (ou o seu preferido) a uma publicação em CDN como AWS Cloudfront.

Espero que esse guia de recomendações seja útil para sua evolução, deixe suas dúvidas nos comentários para complementarmos.

Adendo: Não sabe bem o que é PWA? Leia o resumo.

Colocou a App em produção? Vamos conversar.

Você não conseguirá impedir erros em produção e principalmente lidar com isso na interação com o usuário mesmo que sua aplicação tenha uma cobertura de 100% com testes unitários, um bom ratio pra cada linha de código e testes de aceitação/integração.

Você está errado em todas as metodologias se não testa de forma automatizada.

Reagindo a erros não esperados

A versão 16 do React trouxe um método excelente no ciclo de vida dos componentes, o componentDidCatch, que captura todas as exceções lançadas pelos nós abaixo na árvore do componente que manipula esse método.

Em outras palavras, todo erro que acontecer abaixo de ErrorBoundary (ver código seguinte) será capturado num único ponto sem a necessidade de espalhar try/catch pelo código de apresentação.

De qualquer forma, todas as transformações de estado devem ser concentradas no redux como o código a seguir.

https://gist.github.com/cmilfont/e4fa20e1ced19a36fcdf948916184ade

Independente de como mostrar a UI para o usuário ao acontecer um erro, essa informação virá exclusivamente de um ponto que é administrado por transações das sagas.

Estado Centralizado

Temos vários vantagens em centralizar a manipulação de erros no redux, a principal é que podemos concentrar o monitoramento em um único lugar com os dados trackeados pelo sua ferramenta, seja Airbreak, Logentries ou Sentry.

https://gist.github.com/cmilfont/a0009b8e0af3e4ce0eb1e23439324314

Qual a diferença entre colocar um window.onError?

Facilitar coordenar tipos de erros junto ao estado da aplicação, além de indicar um único ponto de manutenção porque esses tipos precisam de transformações e Tracking.

Track dos erros

Dado a centralização dos erros, agora partir para logar direto no seu serviço que provavelmente tem dezenas de métodos de notificações e habilitar a integração com seu Issue Tracking.

Offline

O ecossistema Redux também agrega a vantagem de facilitar a persistência dos erros para tracking e análise futura ou evitar a submissão constante de notificações aproveitando para enviar em Batch num tempo determinado.

Em alguns casos extremos, principalmente em integração, você pode exportar o store na window para disparar um error que extrapola a aplicação com window.onError = error=> (window.store.dispatch({ type: ‘GLOBAL_ERROR’, payload: error }));

Espero que essas dicas agreguem valor a sua App, porque é praticamente impossível evitar erros, é sempre melhor estar preparado pra agir quando eles surgem.

Comenta sobre algo que acontece(u) na sua App que essas dicas ainda não cobrem para eu melhorar o artigo.