Recapitulação do React Native Core Contributor Summit 2024

Todos os anos, os principais colaboradores da Comunidade React Native se reúnem com a equipe do React Native para moldar colaborativamente a direção deste projeto.

O ano passado não foi diferente — com pequenas exceções. Geralmente nos encontramos um dia antes React Universe Conf (anteriormente React Native EU) em Pilha de chamadas Sede em Wrocław. Em 2024, aprendendo com experiências passadas, organizámos a Cimeira durante dois dias consecutivos, para que possamos ter mais tempo não estruturado juntos.

Essa tradição anual se tornou uma oportunidade valiosa para os colaboradores compartilharem insights e expressarem suas preocupações, e para a equipe principal compartilhar seus planos e coletar feedback dos principais colaboradores do ecossistema React Native — incluindo empresas parceiras, autores de bibliotecas individuais e amigos.

Dividimos a Cimeira em duas vertentes que abrangem os seguintes temas:

• Lançamentos
• O que vem depois da Nova Arquitetura?
• Especificação de APIs da Web para módulos nativos
• LeanCore 2.0
• Módulos Nitro — Desbloqueando componentes de visualização expondo props como jsi::Values
• Plataformas Out Of Tree e CocoaPods
• React Native na área de trabalho

Nesta postagem do blog, gostaríamos de dar uma prévia dos resultados deste encontro.

Lançamentos

Tivemos uma extensa discussão sobre o processo de lançamento do React Native. A equipe principal aprecia o valor de ter colaboradores de fora do Meta envolvidos em lançamentos e enfatiza a importância de ter lançamentos noturnos, que são particularmente benéficos para plataformas fora da árvore, como React Native visionOS, mantenedores de bibliotecas (Reanimated) e frameworks (Expo). Discutimos a frequência dos lançamentos, com algumas pessoas pedindo lançamentos mais 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 discutimos maneiras de reduzir alterações não intencionais e melhorar a comunicação sobre compatibilidade entre React Native e dependências de terceiros.

Esta sessão mostrou o quão complexo é gerenciar lançamentos para React Native e o quão delicado esse tópico é, dadas todas as diferentes partes do ecossistema que precisam ser consideradas.

O que vem depois da Nova Arquitetura?

Agora que a Nova Arquitetura foi lançada como estável, discutimos no que devemos nos concentrar a seguir. Qual poderia ser a próxima grande novidade? Os tópicos giravam em torno de:

• Compatibilidade com a Web — concluiu 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 a funcionalidade multiplataforma adequada no núcleo do React Native.
• Estabilizando a API principal — Acontece que precisamos de mais consenso sobre o que isso significa para desenvolvedores de aplicativos, autores de bibliotecas e plataformas Out-of-Tree. Por exemplo, pode ser necessário extrair lógica nativa da plataforma para iOS e Android da base de código C++ compartilhada. Parte disso foi abordada pela discussão do LeanCore 2.0.
• Suporte de arquitetura antiga — como esperado, a equipe confirmou que os novos recursos do React 19 baseados em renderização simultânea não funcionarão na arquitetura antiga. Novos recursos são direcionados principalmente para a nova arquitetura. Devido aos bloqueadores no cronograma de lançamento do React 19, ainda não está claro onde traçar a linha entre a funcionalidade suportada pela arquitetura nova e antiga.
• Bibliotecas de terceiros para React Native — hoje, nós, autores de bibliotecas, podemos usar TurboModules, ExpoModules e, recentemente, NitroModules para atingir o mesmo objetivo de unir a funcionalidade da plataforma nativa. Precisamos de melhor documentação sobre como fazer isso bem.
• Documentos de Brownfield — na época da cúpula, a documentação oficial para integrar o React Native em aplicativos nativos estava bastante desatualizada. Desde então, a equipe deu continuidade com documentos atualizados e mais simples para Android e iOS.
• Agitação de árvores para a web do Metro — A equipe principal do Metro está aberta a unir o trabalho da equipe da Expo nesta área.

APIs da Web para módulos nativos

Esta sessão foi dedicada ao RFC da Microsoft, que gira em torno da ideia de trazer um subconjunto de APIs da Web para o React Native. O objetivo é aprimorar a escalabilidade do React Native e atrair mais desenvolvedores web aproveitando APIs familiares. Abrindo acesso a uma riqueza de bibliotecas web de código aberto existentes que não têm suporte explícito ao React Native.

Padronizar as especificações da API da Web não é apenas benéfico, mas também essencial para o crescimento do React Native e se alinha bem com nossa visão de muitas plataformas e projeto react-strict-dom. A web oferece uma interface unificada por meio de suas especificações, que os módulos da comunidade React Native atualmente não possuem. A Microsoft identificou cerca de 200 APIs da Web essenciais que poderiam ser implementadas primeiro para plataformas que suportam: iOS, Android, Windows e macOS.

Incentivamos os desenvolvedores de bibliotecas a alinhar suas APIs com as especificações da web sempre que possível, pois essa padronização melhorará a portabilidade do código e a experiência do desenvolvedor em todas as plataformas.

Embora a proposta pareça benéfica para o futuro do React Native, ainda estamos pensando nos 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 divergência em relação à especificação oficial caso uma plataforma específica permita comportamentos não especificados pelo W3C. Precisaríamos descobrir como evitar agrupar módulos desnecessários, por exemplo, com um plugin Babel. Sem mencionar que o escopo dessa iniciativa é bastante amplo.

A conclusão da sessão reforçou dois pontos principais: primeiro, há um forte alinhamento em toda a comunidade React Native na adoção de especificações compatíveis com a web sempre que possível. Em segundo lugar, precisamos estabelecer uma estratégia técnica clara sobre como essas implementações de API da Web podem ser mantidas separadamente para diferentes plataformas. A Microsoft, juntamente com a Callstack, poderia trabalhar no refinamento do RFC original e produzir uma implementação de prova de conceito para um número menor de APIs como uma iniciativa comunitária. Essa abordagem incremental nos ajudará a validar a experiência de design e desenvolvedor antes de expandir o escopo.

LeanCore 2.0

Em 2019, a equipe React Native iniciou a iniciativa Lean Core. O objetivo era abordar a área de superfície do núcleo do React Native e reduzir APIs e componentes desatualizados e legados. Desde então, os componentes React Native e as superfícies da API já deveriam ter passado por outra rodada de limpeza há muito tempo.

Hoje, há muitos componentes que não estão sendo mantidos ativamente com melhores alternativas comunitárias. Além disso, existem componentes que possuem duplicatas que eventualmente deverão ser consolidadas para manutenção.

No lado da API, muitas das APIs da camada JS estão vinculadas a implementações nativas do iOS e Android, em vez de serem verdadeiramente independentes de plataforma. Por exemplo, com Pressable, temos adereços como android_disableSound e android_ripple. O ideal é que os componentes do React Native tenham a menor superfície de API possível que não esteja vinculada a nenhuma plataforma específica.

À medida que as plataformas Out-of-Tree estão crescendo e sendo mais adotadas pelo ecossistema, é preciso haver um caminho para reduzir a superfície de componentes e APIs do núcleo do React Native, reduzindo a carga na equipe principal do React Native e também tornando significativamente mais fácil para os mantenedores da plataforma e da biblioteca Out-of-Tree se manterem atualizados.

Como bônus adicional, isso tornaria mais fácil para desenvolvedores de aplicativos iniciantes aprenderem o React Native, pois há menos componentes duplicados e “pegadinhas” para eles aprenderem. Onde houver uma alternativa comunitária melhor, os desenvolvedores podem ser sinalizados e incentivados a usar as alternativas comunitárias disponíveis.

Durante a sessão, discutimos:

• As motivações de alto nível do Lean Core e os benefícios para as partes envolvidas (desenvolvedores, mantenedores de bibliotecas, Meta)
• Uma visão agregada de quais componentes estão sendo usados em alguns aplicativos React Native de produção do mundo real
• Os critérios do que é um candidato a ser removido do núcleo
• Um plano de ação claro para executar o Lean Core 2.0 com:
• O processo de alto nível para depreciação
• Lidar com casos em que o Meta está usando componentes internamente que têm melhores alternativas de comunidade,

Como próximo passo, um grupo dos principais colaboradores analisará a recolha de mais telemetria e dados, a avaliação de alternativas comunitárias e a elaboração de um RFC detalhando as alterações propostas.

Módulos Nitro — Desbloqueando componentes de visualização expondo props como jsi::Values

Recentemente, Marc Rousavy introduziu os Módulos Nitro como uma abordagem alternativa para criar Módulos Nativos. Os módulos Nitro utilizam o C++ Swift Interop experimental e incorporam uma série de melhorias que podem levar a um melhor desempenho em determinados cenários. Entretanto, durante esta sessão, discutimos as várias compensações envolvidas entre os Módulos Nitro e os TurboMódulos existentes.

Embora os módulos Nitro ofereçam alguns benefícios de desempenho, eles também têm limitações e considerações que precisam ser abordadas. Por exemplo, o uso de recursos experimentais de interoperabilidade pode introduzir problemas de complexidade ou compatibilidade que não estão presentes no TurboModules. Nossa discussão se concentrou nessas compensações e no potencial de atualizar algumas das melhorias do Nitro Modules no React Native Core, o que poderia permitir que os desenvolvedores se beneficiassem de módulos de maior desempenho para todos.

Plataformas fora da árvore e CocoaPods

Out-of-Tree Platforms apresenta todo o poder do React Native, onde podemos compartilhar uma base de código JS entre diferentes plataformas em execução em nossos dispositivos móveis, desktops ou até mesmo em dispositivos VR/XR. Criar tal plataforma atualmente não é o processo mais fácil; na verdade, não há diretrizes sobre como as coisas devem ser criadas, desenvolvidas e mantidas. O React Native Core também está vinculado às plataformas Android e iOS. No futuro, poderemos almejar um cenário em que todas as plataformas sejam tratadas igualmente e integradas a um núcleo C++/JS por meio das mesmas APIs.

Durante esta sessão, mantenedores de diferentes plataformas discutiram quais são os problemas, com o que eles lutam e qual deve ser a solução para unificar o processo de criação e manutenção de novas plataformas Out-of-Tree.

Outro aspecto desta sessão foi discutir CocoaPods e planos futuros relacionados ao gerenciamento de dependências nativas. Recentemente, a equipe do CocoaPods anunciou que passou para o modo de manutenção e que novas melhorias ou recursos importantes não serão enviados. Existem várias alternativas que poderiam ser utilizadas e durante esta sessão discutimos os seus prós e contras e como seria a migração.

React Native na área de trabalho

Steven e Saad, da Microsoft, mantenedores do react-native-windows e do react-native-macos, organizaram uma sessão para ouvir e coletar feedback de colaboradores relacionados às plataformas Desktop. Os tópicos discutidos incluíram explorar como aumentar a adoção do React Native para Desktop (como ter um fluxo de trabalho dedicado no Visual Studio ou expor o desktop como parte do Nx), bem como como dar suporte ao Expo, que é um ponto problemático constante para mais adoção.

Há uma grande discrepância na disponibilidade de módulos comunitários entre o macOS e o Windows, em grande parte devido ao fato de que o código iOS é compatível principalmente com o macOS, enquanto o RNW precisa de implementações personalizadas. Ao trabalhar na Nova Arquitetura do React Native para Windows, a equipe vê potencial nos módulos C++, permitindo ainda mais compartilhamento de código entre plataformas, o que, espera-se, aliviará o fardo de segmentar plataformas de desktop. Vale ressaltar que, do lado da comunidade, a Software Mansion está trabalhando para adicionar suporte de desktop para seus módulos mais populares, como React Native Screens, Gesture Handler e Reanimated.

Ainda estamos impressionados com a forma como passar várias horas juntos por alguns dias resultou em tanto compartilhamento de conhecimento e polinização cruzada de ideias. Durante esta cimeira, plantámos as sementes para iniciativas que nos ajudarão a melhorar e remodelar o ecossistema React Native.

Se você estiver interessado em participar do desenvolvimento do React Native, certifique-se de participar de nossas iniciativas abertas e ler o guia de contribuição temos em nosso site. Esperamos conhecê-lo pessoalmente também no futuro!