Minimizando código duplicado com React Native no Elo7

Início

Quando entrei no Elo7, estávamos engatinhando no mundo dos aplicativos, tínhamos uma versão apenas para o Android, que era basicamente um wrapper de um conjunto de webviews, com um drawer menu nativo. Olhando o roadmap, percebemos que logo atacaríamos uma versão mais nativa (sem tantos webviews) para o iOS e Android. O tempo foi passando e logo as versões mais nativas foram amadurecendo. Então, percebemos que havia uma quantidade de código semelhante* em ambas plataformas: consumo de um endpoint/API, mapeamento de um JSON para um modelo e exibição na tela, etc.

*Semelhante = códigos que fazem exatamente a mesma coisa, porém em linguagens diferentes (Android = Java, iOS = Objective-C)

Com essas informações, definimos que iríamos minimizar esse código dúplicado, com a premissa de criar aplicativos nativos. Fomos atrás de material na internet e encontramos o Djinni, do Dropbox, que tinha uma proposta alinhada com algo que procurávamos, porém apenas a camada de UI (User Interface), teria que ser escrita em cada plataforma. Fizemos algumas provas de conceito e o resultado não foi o que esperávamos, o código escrito usando o Djinni era em C++, não abstraía a camada de UI e ainda assim era complexo de integrar com apps já existentes. Então assumimos que a melhor maneira de construir aplicativos na época, era manter a abordagem que já estava dando certo, cada plataforma com o seu código.

Meio

Novamente, olhando o roadmap, vimos que desenvolveríamos mais dois aplicativos destinados aos vendedores que, por sua vez, teriam algumas features já presentes nos aplicativos dos compradores (já mencionados). Nessa época, decidimos modularizar o que seria semelhante em mais de um aplicativo. Lembrando que ainda nesse ponto, não compartilhávamos código entre plataformas (Android e iOS). Dividimos as aplicações em libraries do iOS e Android: módulo de mensagens - responsável por abstrair quase tudo que tem relação com o nosso fluxo de troca de mensagens; módulo commons - responsável por abstrair fluxo de login, tela de perfil e tudo que considerávamos comum entre os aplicativos; módulo networking - responsável por abstrair nossa camada HTTP;

Segue uma descrição resumida do cenário do Android, visto que do iOS é muito semelhante, ele será omitido:

Talk7 consome as libraries:

• módulo de mensagens
• módulo commons
• módulo networking

Elo7 consome as libraries:

• módulo de mensagens
• módulo commons
• módulo networking

Com essa estrutura e a famosa Clean Architecture, alcançamos um reaproveitamento de código legal, com todas aquelas vantagens de evitar código duplicado que todo mundo já conhece, tem até uma palestra minha com o Thiago Pilon que falamos bastante a respeito da arquitetura que adotamos na época. (Thiago Pilon)

Fim (pelo menos até agora)

Eis que algumas pessoas/empresas não paravam de falar que o React-Native (RN) era uma solução elegante para compartilhamento de código entre plataformas, que é uma ferramenta que permite escrever aplicativos nativos usando React e Javascript e tem como diretiva: aprenda uma vez e escreva aplicativos para as duas plataformas (Android e iOS, eventualmente até aplicações WPF/Phone para Windows).

A proposta do RN é ambiciosa, gerar código nativo, componentes de UI nativos, integração com código já existente, toolset bem completo e até possibilidade de atualização de aplicativos já instalados.

Esses dois últimos pontos chamaram bastante nossa atenção, poderiamos colocar o RN na nossa base de código sem reescrever todo o projeto, uma vez que a integração com a parte nativa era possível e também poderíamos subir uma correção de bug sem a necessidade de passar por todo o processo de review/aprovação da Apple, isso sem falar que teríamos nossa base inteira atualizada em pouco tempo. <3

Prova de conceito

Concluímos que a proposta do RN casava muito bem com aquela premissa lá do começo do post, de evitar código duplicado entre as plataformas (Android e iOS), então decidimos avaliar. Fizemos nossa prova de conceito e obtivemos sucesso, porém a integração deu bastante trabalho, e até que chegássemos à uma solução production-ready, investimos muito esforço. O problema era que os mantenedores do RN estão acostumados com uma estrutura de diretórios diferente da que temos aqui e não queríamos mudar nossa estrutura atual, afetando a produtividade do time modificando a maneira de trabalhar.. Então, tomamos a ousada decisão de fazer a integração de uma forma bem diferente da sugerida.

Estrutura de diretórios sugerida:

ios/
android/
package.json
src/
node_modules/
...

Ou seja, nosso projeto estaria acoplado ao RN :/, e não queríamos isso, pois se um dia abandonarmos a ideia de utilizar RN, poderíamos simplesmente removê-lo. :) Por essa motivação, gostaríamos que a lib que abstraísse o RN também fosse uma dependência dos aplicativos atuais, algo como:

Talk7 consome as libraries:

• lib de mensagens
• lib commons
• lib networking
• lib react native

Após um tempo investido, aproximadamente 1 mês, alcançamos esse objetivo. O único incômodo causado para a parte do time que não estava totalmente envolvida com essa integração, era a instalação do NPM para podermos gerar o bundle com os componentes escritos em RN. Acredito que a explicação de como integramos o RN nos aplicativos daqui vale um outro post, pois é um tema bem extenso e não está no escopo do tema deste post.

Hoje

No Elo7, o RN vem cumprindo seu objetivo, por isso já temos diversas features feitas inteiramente em RN, que se comunicam com o nosso backend e são exibidas nas plataformas Android e iOS, compartilhando código Javascript de fácil manutenção.

Bom, mas e a experiência do usuário, como fica? Não precisa ser igual, se você precisar de customizações específicas para cada plataforma, o RN resolve muito bem, vale a pena conferir.

Aqui vai um exemplo de código em React Native, bem simples, com o objetivo de exibir um pouco a forma que utilizamos o RN aqui no Elo7:

Caso tenha dúvidas ou sugestões, pode comentar abaixo. (:

Obrigado Thiago Pilon pela revisão e sugestões!

• react-native
• ios
• android