Lições aprendidas no mundo React

Boas práticas pra eu nunca esquecer

Depois de longos meses ensinando, fazendo algumas consultorias, analisando e escrevendo código em React, cheguei nesse conjunto de boas práticas que escrevi num papel e fico me lembrando pra não errar:

Tudo é componente

Pára de pensar em página, em template, em DOM e ter medo de acionar o render, isso não está manipulando DOM.

Até a manipulação de rotas é apenas o comportamento de um componente que está mais próximo da raiz e utiliza o ciclo de vida dos componentes para reorganizar a árvore.

Cada galho é uma árvore independente

Cada componente é responsável por orquestrar seus filhos, mas não conhece o pai e nem seus irmãos, apenas troca mensagens por funções recebidas no props que magicamente ele sabe que existe e deve acionar, mas não sabe o que faz.

Universos imutáveis

Não ter medo de acionar o render é manter o universo sempre num estado válido e imutável, recomponha sempre sua árvore e pense nela apenas.

A sua interface gráfica é o que está no return do render, ela é imutável, sem código (sem scriptlet, apenas marcação) e deve sempre representar o estado do universo, não dados isolados.

Só existe const

Pára de escrever let (bem, var voce já deve ou deveria ter parado). Quando você trabalha com universos imutáveis, a interface representa o estado dele e você não precisa de variáveis, apenas de constantes.

Dessa forma se mantém o mais fiel possível à imutabilidade. Pensa comigo, se tem necessidade de mudar um valor, não vai ser atribuindo diretamente na propriedade, é reconstruindo o universo.

Dê preferência a Props

Tem casos que é impossível (do tipo ainda não consegui Mindset necessário) deixar de usar o state, mas usar como regra sempre expor os dados em uma fonte read-only te mantém na imutabilidade.

Centralize a fonte dos dados

Flux é o padrão, mas o único razoável pra manter o código saudável dentro dessa abordagem é o redux, foquemos nele.

Só vai existir uma única fonte de dados que parte da raiz da sua árvore que representa a aplicação inteira (dentro do possível).

Crie Buracos Negros

Eu por exemplo que já enfrentei e enfrento integrações, tento minimizar isso criando pequenos universos que trocam informações por meio do store. Caso tenha essa necessidade, acione uma outra árvore apenas por meio do Provider dela.

Evite dados repetidos

Não podem existir estados diferentes para um mesmo modelo em um universo imutável.

Concentre as mudanças nas Sagas

Existe apenas um D’us que pode interceder por vós, não sei como ele é, mas deixou um local pra você concentrar sua orações, realize as mudanças de estado desse universo para criação de um outro válido apenas no redux-saga.

Na hora que estiver fazendo seus testes unitários se lembrará desse sermão.

Dê preferência a funções puras

Vai agradecer também quando estiver testando, é mais fácil manter imutabilidade em uma função que apenas representa uma interface que aciona outras functions conforme a interação do usuário.

Um detalhe especial pra decorators, eu aboli o uso por causa dos testes, é muito trabalhoso mockar.

Finalizando

São boas práticas mais abstratas, cada ferramenta tem também seu conjunto interno de boas práticas, mais pesquisas se mostram necessárias.

Pra quem já trabalha/estuda o mundo React esse texto fará algum sentido, se mora em Fortaleza eu posso ajudar num curso presencial 😀

Frameworks Caseiros

Todo Framework de sucesso nasce da abstração de uma solução que funcionou… que nasceu caseiro.

Não é de hoje que falo sobre esse assunto, inclusive a última vez que escrevi foi em 2009. #leião!

Continuam os mesmos argumentos, só que eu tinha uma linguagem um pouco agressiva, dêem o desconto, eram os hormônios juvenis!

Porque usamos JSF em pleno 2016?

O mercado corporativo hoje, ou pejorativamente chamado de Enterprisey, é o principal consumidor de soluções atrasadas pra resolverem problemas que já foram resolvidos na última década ou há poucos anos. Ponham governos como corporativos na conta.

Em parte porque não dá pra reescrever aplicações todo semestre como a garotada que sonha em trabalhar em Startup deseja, mas o principal é que são órfãos de Guidelines já validadas.

Explico focando no Front End, use como analogia para as outras áreas.

Que desafios tem um Twitter, Instagram, SnapChat, WhatsApp, [ponha a Startup BI que voce prefere aqui]?

Nenhum!

Com tecnologias de hoje você faz um desses em um sábado aprendendo um conjunto de ferramentas e tomando cerveja. Os desafios são os problemas e como resolvem, hoje em termos de Front End o maior desafio é a cola com o Back End do que outra coisa como: Payload, Sincronização, Middleware, Offline e Segurança.

Interfaces Gráficas estão resolvidas, navegação está resolvida.

React, o JSF que deu certo

Tem gente que chega pra mim e diz que veio fazer o curso de React só pra saber o que escolhi.

Parece engraçado, mas não é nada ingênuo, a verdade oculta e trágica por trás é que a maioria dessas empresas corporativas tem realmente desafios no Front End.

São sistemas Commodities, mas nem por isso menos importantes, são quem fazem a economia gerar e urgem pela necessidade de orientação e um guia.

Pega o Back End, exageradamente falando tudo está resolvido há mais de 10 anos.

Os desafios de outrora eram como organizar o código, depois nos anos 90 foi como trabalhar em rede, na última meia década era como escalar, agora é como orquestrar e monitorar isso tudo. Mas em termos de tecnologias e padrões já tem um Guideline muito estabelecido há tempos.

Trás pro Front End, ainda estávamos tentando resolver Interfaces Gráficas desde os anos 90.

Geralmente essas corporações, aqui focando no Front, não acompanharam a evolução da última década, continuaram desenvolvendo com o que tem já tinham feito esperando aquele momento que as coisas estariam estabelecidas como no Back, só que esse momento chegou muito bruscamente nos últimos quatro ou cinco anos.

JSF era uma boa idéia em 2000/2001 quando foi concebido, o problema era que não tínhamos a tecnologia certa pra fazer isso e nem o lugar certo. Componentizar, ter um ciclo de vida, interfaces que reagem a mudanças, MVC mais próximo do original lá do Desktop é tudo de bom.

E o que Framework Caseiro™ tem a ver com utilizar soluções corretas?

Nunca foi correto usar essa abordagem e se ainda é feito até hoje a causa é justamente por causa desse vácuo de uma boa definição de como resolver esses problemas do Front End.

Isso abre portas para as corporações construírem suas Guidelines com soluções desenvolvidas em casa (leiam os links do primeiro parágrafo), misturadas com o que dá pra aprender na correria das entregas.

Algo que percebi de forma empírica nos cursos que faço:

1 – Os alunos pedem um material pra estudar antes;

2 – Eu indico a própria documentação das ferramentas como o React e Redux;

3 – Ninguém consegue compreender qual a vantagem em relação a outras abordagens, já que numa primeira leitura sempre parece mais complicado e realmente é se você não está no Mindset apropriado.

No curso eu sempre apresento quais são os problemas que tenho e como o React e o Redux resolvem magistralmente e porque a forma escolhida foi aquela abordagem sintática e programática.

Então pequenos momentos de WOW são conseguidos, porque agora aquele código faz sentido no README do projeto no Github. Essa é uma das falhas principais de quase ninguém entender porque o React é tão bom e tem crescido tanto quando olha a documentação, não apresentam o que ele resolve, apenas como.

O cenário de hoje é uma mistura de versões e até Frameworks diferentes na mesma App com muito código inventado e fechado.

Finalizando, se sua empresa sofre desse mal de código demais feito em casa no Front End, apresente esse texto e vamos discutir sobre esses Guidelines modernos!

Comunicação deve ser clara

Estou colhendo Feedback sobre a palestra que ministrei no FrontIn Fortaleza no sábado último (17/09/2016).

Coloquei no último campo do formulário:


E obtenho uma resposta que não era objetivo, observa a última da lista:


A resposta está correta, eu fiz uma pergunta no local de descrição (portanto, ajuda) do que se refere aquela opção.

Troquei agora pra:


Aonde eu conduzo o participante para a resposta que eu gostaria que fosse informado naquele local.

Os pequenos detalhes são muito importantes para atingir os objetivos.