A cada ano, os contribuidores-chave da comunidade React Native se reúnem com a equipe do React Native para moldar coletivamente o rumo deste projeto.
No ano passado não foi diferente — com uma pequena exceção. Geralmente nos reunimos um dia antes do React Universe Conf (anteriormente React Native EU) na sede da Callstack em Wrocław. Em 2024, aprendendo com experiências passadas, hospedamos o Summit por dois dias consecutivos para que pudéssemos ter mais tempo não estruturado juntos.
Esta tradição anual tornou-se uma oportunidade valiosa para os contribuidores compartilharem insights e expressarem suas preocupações, e para a equipe-chave compartilhar seus planos e coletar feedback de importantes contribuidores ao ecossistema React Native — incluindo empresas parceiras, autores individuais de bibliotecas e amigos.
Dividimos o Summit em duas trilhas abordando os seguintes tópicos:
Neste post do blog, gostaríamos de dar uma prévia dos resultados desta reunião.
Lançamentos
Tivemos uma discussão extensa sobre o processo de lançamento do React Native. A equipe-chave aprecia o valor de ter contribuidores externos à Meta envolvidos nos lançamentos e enfatiza a importância dos lançamentos noturnos, que são particularmente benéficos para plataformas fora da árvore como React Native visionOS, mantenedores de bibliotecas (Reanimated) e estruturas (Expo). Discutimos a frequência dos lançamentos, com algumas pessoas pedindo por mais lançamentos frequentes para enviar correções mais rapidamente, enquanto outras expressaram preocupações sobre o impacto nas bibliotecas de terceiros e nos esforços de atualização.
Também brainstormamos maneiras de reduzir as mudanças inesperadas que quebram a compatibilidade e melhorar a comunicação sobre a compatibilidade entre React Native e dependências de terceiros.
Esta sessão mostrou como complexo é gerenciar os lançamentos do React Native, e quão delicado este tópico é, considerando todas as diferentes partes do ecossistema que precisam ser levadas em conta.
O que vem depois da Nova Arquitetura?
Agora que a Nova Arquitetura foi lançada como estável, discutimos o que devemos focar em seguida. Qual poderia ser a próxima grande coisa? Os tópicos giraram em torno de:
- Compatibilidade com o web – concluído na discussão sobre a direção do projeto React Strict DOM, que deve ser tratado como um polyfill temporário, enquanto a equipe Xplat implementa funcionalidades cross-platform adequadas no núcleo do React Native.
- Estabilizando a API principal – descobriu-se que precisamos de mais consenso sobre o que isso significa para desenvolvedores de aplicativos, autores de bibliotecas e plataformas fora da árvore. Por exemplo, pode ser necessário extrair a lógica nativa do iOS e Android do código base compartilhado C++. Parte disso foi abordada na discussão sobre LeanCore 2.0.
- Suporte à arquitetura antiga – como esperado, a equipe confirmou que as novas funcionalidades do React 19 baseadas em renderização concorrente não funcionarão na arquitetura antiga. As novas funcionalidades são principalmente direcionadas para a nova arquitetura. Devido aos bloqueios no cronograma de lançamento do React 19, ainda é incerto onde traçar a linha entre as funcionalidades suportadas por ambas as arquiteturas.
- Bibliotecas de terceiros para o React Native – hoje podemos usar TurboModules, ExpoModules e recentemente NitroModules como autores de bibliotecas para alcançar o mesmo objetivo de conectar a funcionalidade nativa da plataforma. Precisamos de melhor documentação sobre como fazer isso bem.
- Docs brownfield – no momento do evento, a documentação oficial para integrar React Native em aplicativos nativos estava bastante datada. Desde então, a equipe seguiu com documentos atualizados e mais simples para Android e iOS.
- Tree-shaking para Metro web – a equipe principal do Metro está aberta a incorporar o trabalho da equipe Expo nessa área.
APIs Web para Módulos Nativos
Esta sessão foi dedicada à RFC da Microsoft em torno da ideia de trazer um subconjunto de APIs Web para o React Native. Visa melhorar a escalabilidade do React Native e atrair mais desenvolvedores web ao aproveitar APIs familiares. Abre acesso a uma riqueza de bibliotecas open-source web que não têm suporte explícito para o React Native.
Padronizar-se em especificações de API Web não só é benéfico, mas também essencial para o crescimento do React Native e se alinha bem com nossa visão de Many Platforms e projeto react-strict-dom. A web oferece uma interface unificada através de suas especificações, que os módulos da comunidade React Native atualmente carecem. A Microsoft identificou cerca de 200 APIs Web essenciais que poderiam ser implementadas primeiro para plataformas que eles suportam: iOS, Android, Windows e macOS.
Encorajamos desenvolvedores de bibliotecas a alinharem suas APIs com especificações web sempre que possível, pois essa padronização melhorará a portabilidade do código e a experiência do desenvolvedor em diferentes plataformas.
Ao mesmo tempo, enquanto a proposta parece benéfica para o futuro do React Native, ainda estamos brainstorming sobre os próximos passos. Uma preocupação que notamos é a governança das APIs e se elas precisariam viver em um repositório separado das implementações da plataforma. Outra é divergir da especificação oficial no caso de uma plataforma permitir comportamentos não especificados pelo W3C. Precisaríamos descobrir como evitar o agrupamento de módulos desnecessários, por exemplo, com um plugin Babel. Não se pode negar que a escala dessa iniciativa é bastante grande.
A conclusão da sessão reforçou dois pontos-chave: primeiro, há uma forte alinhamento na comunidade React Native em adotar especificações compatíveis com o web sempre que possível. Segundo, precisamos estabelecer uma estratégia técnica clara para como essas implementações de API Web podem ser mantidas separadamente para diferentes plataformas. A Microsoft junto com a Callstack poderia trabalhar na refinação da RFC original e produzir uma implementação de prova de conceito para um número menor de APIs como iniciativa da comunidade. Essa abordagem incremental nos ajudará a validar o design e a experiência do desenvolvedor antes de expandir o escopo.
LeanCore 2.0
Em 2019, a equipe React Native iniciou a iniciação Lean Core. O objetivo era abordar o escopo da base do React Native e reduzir APIs e componentes que estavam desatualizados e legados. Desde então, os componentes React Native e as superfícies de API estão há muito tempo precisando de uma nova limpeza.
Hoje, existem muitos componentes que não são mantidos ativamente com alternativas melhores da comunidade. Além disso, existem componentes duplicados que eventualmente devem ser consolidados para manutenção.
No lado das APIs, muitas das APIs do JS estão vinculadas às implementações nativas iOS & Android, em vez de serem verdadeiramente agnósticas a plataformas. Por exemplo, com Pressable, temos propriedades como android_disableSound e android_ripple. Idealmente, os componentes React Native devem ter uma superfície de API o menor possível que não está vinculada a nenhuma plataforma específica.
A medida que as plataformas Fora-da-Árvore estão crescendo e sendo adotadas mais pela ecossistema, é necessário um caminho para reduzir a superfície de componentes e API do React Native core, reduzindo a carga sobre a equipe React Native core e também tornando significativamente mais fácil para os mantenedores de plataformas Fora-da-Árvore & bibliotecas ficarem atualizados.
Como um bônus adicional, isso facilitaria para desenvolvedores iniciantes pegar o React Native, pois existem menos componentes duplicados e
Plataformas fora da árvore e CocoaPods
As Plataformas Fora da Árvore apresentam todo o poder do React Native, onde podemos compartilhar uma base de código JS entre diferentes plataformas em nossos dispositivos móveis, desktops ou até mesmo em dispositivos VR/XR. Criar tal plataforma atualmente não é um processo fácil, na verdade, não há diretrizes sobre como as coisas devem ser criadas, desenvolvidas e mantidas. Além disso, o React Native Core está de certa forma vinculado às plataformas Android e iOS. No futuro, poderíamos visar uma situação em que todas as plataformas são tratadas igualmente e integradas com um núcleo C++/JS através das mesmas APIs.
Durante esta sessão, mantenedores de diferentes plataformas discutiram os problemas que enfrentam e o que deveria ser a solução para unificar o processo de criação e manutenção de novas Plataformas Fora da Árvore.
Outro aspecto desta sessão foi discutir CocoaPods e planos futuros relacionados à gestão de dependências nativas. Recentemente, a equipe do CocoaPods anunciou que eles entraram em modo de manutenção e novas melhorias ou recursos principais não serão enviadas. Existem várias alternativas que podem ser usadas e durante esta sessão discutimos suas vantagens e desvantagens, bem como o que uma migração poderia parecer.
React Native no Desktop
Steven e Saad da Microsoft, mantenedores de react-native-windows e react-native-macos, hospedaram uma sessão para ouvir e coletar feedback dos contribuidores relacionados às plataformas desktop. Os tópicos discutidos incluíram explorar como aumentar a adoção do React Native no Desktop (como ter um fluxo de trabalho dedicado no Visual Studio, ou expor o desktop como parte do Nx), bem como como suportar o Expo, que é um ponto doloroso contínuo para mais adoção.
Há uma grande discrepância na disponibilidade de módulos da comunidade entre macOS e Windows, principalmente devido ao fato de que o código iOS é compatível em grande parte com macOS, enquanto o RNW precisa de implementações personalizadas. Enquanto trabalham no Novo Arquitetura para React Native for Windows, a equipe vê potencial nos módulos C++ permitindo ainda mais compartilhamento de código entre plataformas, o que esperamos aliviar a carga de atingir plataformas desktop. Vale ressaltar que do lado da comunidade, a Software Mansion está trabalhando em adicionar suporte para desktop aos seus módulos mais populares, como React Native Screens, Gesture Handler e Reanimated.
Ainda estamos impressionados com o quanto passar algumas horas juntos por alguns dias resultou em tanto compartilhamento de conhecimento e intercâmbio de ideias. Durante esta cúpula, plantamos as sementes para iniciativas que nos ajudarão a melhorar e redesenhar o ecossistema do React Native.
Se você está interessado em participar do desenvolvimento do React Native, certifique-se de se juntar às nossas iniciativas abertas e leia nosso guia de contribuição no site. Esperamos vê-lo pessoalmente também no futuro!