Forem: Luma Montes

Migração de dados entre serviços: estratégias, riscos e trade-offs

Luma Montes — Sun, 18 Jan 2026 21:37:17 +0000

Contexto

Recentemente precisei migrar dezenas de milhares de registros de
auditoria entre dois serviços durante uma task! Era minha primeira vez fazendo uma migração de dados, ainda mais dessa escala e aprendi bastante coisa, então decidi registrar neste artigo.

Basicamente, uma migração de dados envolve pegar um conjunto de informações que estão armazenadas em uma determinada base (seja um banco de dados, uma planilha ou outro formato) e transformá-las para que possam ser consumidas corretamente por outro serviço, respeitando o modelo e as regras esperadas no destino.

As motivações para uma migração são diversas: Em alguns casos, estamos lidando com dados legados que precisam ser movidos para um novo serviço. Em outros, diferentes sistemas passam a compartilhar responsabilidades e precisam de uma interseção consistente de dados. Muitas vezes esse processo acontece de forma planejada, o que permite mais tempo para análise e execução. Mas também pode surgir de maneira urgente, pode ser demanda de um cliente, de um setor ou por uma necessidade operacional inesperada.

A decisão de migrar pode partir tanto do time de produto quanto da engenharia. Ainda assim, é responsabilidade do time de engenharia avaliar e bater o martelo sobre a viabilidade técnica dessa migração! E essa viabilidade depende diretamente do estudo que a gente faz sobre os dados disponíveis.

Por exemplo, quando a demanda vem de produto, normalmente existe um espaço maior para a engenharia investigar complexidade, riscos e custos. Mas nada disso se resolve apenas com um “dá pra migrar, galera! deixa que eu resolvo”. Antes de qualquer compromisso, é muuuuito importante analisar volumetria, estrutura e complexidade dos dados envolvidos.

Um exemplo claro: vale a pena a gente paralisar um ou dois devs por DUAS sprints para migrar 15 registros? Na maioria dos cenários, não. O custo de engenharia pode ser alto demais para um impacto pequeno no produto.

Claro que viabilidade não se resume apenas a números. O contexto do produto também importa. Que tipo de dado está sendo migrado? São dados simples ou recursivos? Existem dependências entre registros? Há estados intermediários, históricos ou regras de negócio acopladas a esses dados? Tudo isso influencia diretamente na decisão.

Uma vez que a migração é considerada viável, fica mais claro o conjunto de problemas que precisam ser resolvidos. Em geral, eles se dividem em três grandes etapas:

Extração: como os dados serão puxados?
Transformação: como esses dados serão adaptados para o formato esperado?
Carregamento: como os dados transformados serão enviados para o serviço de destino?

Foi nesse contexto que eu aprendi sobre ETL, que é uma abordagem criada justamente para organizar e estruturar esse tipo de processo (Parabéns, você também aprendeu o que é ETL :)))

Ainda assim, é importante reforçar: ETL não é bala de prata. Em muitos casos, criar uma aplicação dedicada para migração pode ser uma complexidade desnecessária. Antes de qualquer implementação, é essencial estudar a viabilidade real da migração, entender o formato dos dados de origem, o esforço de transformação e o custo de manter essa solução também.

De forma geral, ETLs fazem mais sentido quando a migração precisa ser executada mais de uma vez ou reaproveitada no futuro. Para migrações pontuais, uma solução mais simples pode ser suficiente e mais segura.

Estratégias

Quando estou lidando com migrações menores, costumo optar por soluções simples. Em especial, gosto bastante de usar Jupyter Notebook, principalmente quando os dados de origem estão em planilhas ou em bases pequenas. Nesses cenários, não vejo muito sentido em construir uma aplicação inteira só para executar um processo pontual.

Criar um notebook é relativamente simples: basta um arquivo com extensão .ipynb e um kernel configurado localmente. Dependendo do contexto, dá para usar Kotlin, Python, Deno, entre outras opções. A grande vantagem aqui é a rapidez para explorar os dados, testar transformações e iterar sem muitas dificuldades.

Já para migrações mais complexas, minha preferência passa a ser criar uma aplicação local que roda via terminal — uma CLI simples, mas controlada. Esse tipo de abordagem permite mais previsibilidade, controle de execução e facilidade para lidar com grandes volumes de dados.

Aqui, uma preocupação fundamental é ter uma estratégia de rollback. Nunca dá para assumir que a migração vai rodar perfeitamente de primeira. Sempre que possível, vale testar em ambiente de staging antes de executar em produção, além de alinhar muito bem o rollout com o time.

A forma de carregar os dados também faz diferença. Em alguns casos, inserir diretamente no banco pode ser suficiente. Em outros, usar uma API ou até publicar eventos em fila é mais seguro, principalmente quando estamos lidando com grandes volumes e queremos processar tudo de forma assíncrona.

No fim das contas, o formato do ETL importa menos do que o objetivo final. Ele pode ser um notebook, uma CLI ou até um script simples — desde que atenda às necessidades de extração, transformação e carregamento de forma segura e previsível.

Desafios práticos que você vai enfrentar

Dados faltando ou inconsistentes

Em migrações reais, é muito comum encontrar dados incompletos, inconsistentes ou marcados como removidos (como casos de soft delete). Esses cenários precisam ser tratados explicitamente, seja ignorando registros, preenchendo valores padrão ou sinalizando dados desconhecidos.

Enriquecimento de dados

Nem sempre todas as informações necessárias estão em um único lugar. Em alguns casos, é preciso bater em outros bancos de dados, outros serviços/apis pra buscar as informações que você precisa. É bom estar de olho nesse ponto desde o início, pois aumenta a complexidade

Trade-offs técnicos

Abaixo estão alguns dos principais trade-offs que enfrentei:

Velocidade vs correção

Quando a migração é urgente, você precisa decidir até onde aceitar inconsistências nos dados sem comprometer a entrega.

Jupyter Notebook vs CLI

Para migrações pequenas, notebook resolve e acelera muito! Mas por experiência própria, ele pode crescer muito e dificultar a legibilidade e manutenção do script. Quando isso acontece, vale mais a pena adotar uma CLI.

Migrar tudo vs migrar só o essencial

Nem todo dado merece ser migrado, é muito importante alinhar com o time de produto quais dados serão preservados e quais dados podemos aceitar como "perdidos", de forma consciente.

Processar tudo de uma vez vs em lotes

Por experiência própria, recomendo ir processando os registros em batches e ir verificando após cada uma se os dados foram da forma esperada. Isso é muito melhor do que ter que processar tudo de uma vez e precisar reprocessar por qualquer errinho nos tratamentos de dados.

Conclusão

Se ninguém percebeu que a migração de dados aconteceu em produção, provavelmente foi um bom sinal. No fim, tudo se resume a contexto, equilíbrio e trade-offs — e a manter o time alinhado sobre o que é possível entregar.

Usando Guard/Wrapper components como alternativa a condições ternárias no React

Luma Montes — Mon, 18 Aug 2025 02:35:02 +0000

Esses dias me deparei com o seguinte código (eu mesma tinha feito ele no meio da madrugada) mais ou menos assim:

isPaid ? (
  <section className="flex-1 flex flex-col xl:flex-row max-w-7xl mx-auto w-full p-4 sm:p-6 gap-6 xl:gap-8">
    <div className="flex-1 flex flex-col gap-6">
      <h2 className="text-lg font-semibold">Pagamento já realizado</h2>
      <p className="text-sm text-gray-500">Obrigado por sua compra!</p>
      <Button variant="outline" onClick={handleClick}>
        Ver comprovante
      </Button>
    </div>
  </section>
) : (
  <>
    {(isPixModalOpen && invoice?.pix) && <PixModal ... />}
    <section className="flex-1 flex flex-col xl:flex-row max-w-7xl mx-auto w-full p-4 sm:p-6 gap-6 xl:gap-8">
      <div className="flex-1 flex flex-col gap-6">
        <PaymentMethodSelector />
        <PaymentDetails />
        <SecurityInfo />
      </div>
      <OrderSummary />
    </section>
  </>
)

Nada de errado até então... um pouco feio, mas é a vida né?

Porém mais um pouco embaixo no código, novamente precisei usar essa condicional:

isPaid ? (
  <div>Conteúdo jsx gigantudo aqui quando pago</div>
) : ( 
  <div>Conteúdo jsx gigantudo quando não pago</div>
)

Depois ainda usei mais algumas vezes, até me dar conta que tava ficando um pouquito feio de ler, por ser ternários com condições muuuito grandes.

Melhorando o código

Pensando nisso e inspirada pelo hook que já vem por padrão no inertia js (WhenVisible), podemos criar um componente que vai encapsular nossa regra de negócio!

Por exemplo:

A versão genérica

Podemos começar criando um componente bem simples:

function WhenVisible({ isVisible, children }) {
  return isVisible ? <>{children}</> : null;
}

Antes:

{isPaid ? (
  <div>Conteúdo do pagamento realizado</div>
) : (
  <div>Formulário de pagamento</div>
)}

Depois:

<WhenVisible isVisible={isPaid}>
  <div>Conteúdo do pagamento realizado</div>
</WhenVisible>

<WhenVisible isVisible={!isPaid}>
  <div>Formulário de pagamento</div>
</WhenVisible>

Versão menos genérica (e mais declarativa)

Também podemos criar componentes ainda mais específicos:

<WhenPaid>
  <div>Conteúdo do pagamento realizado</div>
</WhenPaid>

<WhenNotPaid>
  <div>Formulário de pagamento</div>
</WhenNotPaid>

A implementação:

function WhenPaid({ children }) {
  const { isPaid } = grab() // função que pega as infos da página
  return isPaid ? <>{children}</> : null;
}

function WhenNotPaid({ children }) {
  const { isPaid } = grab()
  return !isPaid ? <>{children}</> : null;
}

Pontos Positivos

1. Legibilidade: O código fica bem legível!!

2. Menos aninhamento: É bem chatinho quando a gente precisa ficar se batendo pra fechar parênteses e chaves de um ternário gigantudo

3. Reutilização: Esses componentes podem ser usados em qualquer lugar da aplicação

4. Testabilidade: Cada estado fica isolado e mais fácil de testar

5. Manutenibilidade: Mudança na lógica? Mexemos só no wrapper component que está em volta, não vai precisar alterar a mesma condição em vários lugares do seu código (tops)

Conditional Wrappers e outras arquiteturas

Também existem várias outras formas de usar essa arquitetura para refatorar código e evitar duplicação:

1. Conditional Wrappers

Sabe aquele código que só aplica um wrapper em certas condições? e aí você acaba repetindo o mesmo código em vários lugares só por causa do wrapper?

// Antes 
{shouldWrap ? (
  <div className="my-wrapper">
    <MyComponent />
  </div>
) : (
  <div className="my-wrapper">
    <MyComponent />
  </div>
)}

// Depois 
function ConditionalWrapper({ condition, wrapper: Wrapper, children }) {
  return condition ? <Wrapper>{children}</Wrapper> : children;
}

<ConditionalWrapper condition={shouldWrap} wrapper={({ children }) => <div className="my-wrapper">{children}</div>}>
  <MyComponent />
</ConditionalWrapper>

2. Role-Based Components

Também vejo esse cara sendo usado bastante na parte de permissionamento, quando temos alguns tipos diferentes de permissão para o usuário, e dependendo da permissão dele, mostramos conteúdos diferentes.

function WhenAdmin({ children }) {
  const { user } = useAuth();
  return user?.role === 'admin' ? <>{children}</> : null;
}

function WhenLoggedIn({ children }) {
  const { isAuthenticated } = useAuth();
  return isAuthenticated ? <>{children}</> : null;
}

// Uso super limpo
<WhenLoggedIn>
  <UserDashboard />
</WhenLoggedIn>

<WhenAdmin>
  <AdminPanel />
</WhenAdmin>

3. Feature Flag Components

Para quando você tem features que só devem ser exibidas se estiverem ativas, como:

function WhenFeatureEnabled({ feature, children }) {
  const { isEnabled } = useFeatureFlags(); // Se isso aqui mudar, iremos alterar de uma vez em vários lugares
  return isEnabled(feature) ? <>{children}</> : null;
}

<WhenFeatureEnabled feature="new-checkout">
  <NewCheckoutFlow />
</WhenFeatureEnabled>

<WhenFeatureEnabled feature="beta-features">
  <BetaFeaturesList />
</WhenFeatureEnabled>

Quando usar (e quando NÃO usar)

Use wrapper components quando:

Você tem a mesma condicional repetida várias vezes
A condicional é complexa (múltiplas condições)
Você quer encapsular lógica de negócio
O código fica mais legível e autodocumentado

Continue tranquilamente com ternários quando:

É uma condicional simples
O ternário deixa o código mais direto
Você não vai reutilizar essa lógica
O simples já funciona - não precisa complicar!

Exemplo onde ternário é perfeito:

// Super direto e claro !
{isLoading ? <Spinner /> : <Content />}
{user.name || 'Usuário Anônimo'}
{count > 0 && <Badge>{count}</Badge>}

Dicas práticas para implementação!

1. Comece simples

Comece com o WhenVisible genérico e só evolua se realmente precisar. Muitas vezes a versão genérica já resolve vários casos!

2. Questione-se sempre: "Isso realmente está melhor?"

Antes de refatorar, se pergunte:

O código ficou mais legível?
A equipe vai entender facilmente?
Estou resolvendo um problema real ou criando complexidade desnecessária?

Ah, e como toda mudança de "padrão", comunique com a sua equipe, pegue uns pitacos e opiniões pra ver se realmente faz sentido no seu caso de uso :)

Eu particularmente achei bem legal principalmente em casos de ternários grandes e difíceis de ler, além dos que são muito aninhados ou ternários com condições repetidas em vários lugares!

O que eu aprendi liderando tecnicamente a criação de um aplicativo de comunicação escolar

Luma Montes — Sat, 09 Aug 2025 22:06:56 +0000

1. Como decidir a stack inicial de um produto mobile?

Valide sempre com a sua equipe a escolha de stack e ferramentas!

No nosso caso, optamos por React Native por conta de alguns motivos como:

Equipe reduzida alocada no projeto
Equipe com experiência prévia em React (e não em desenvolvimento nativo ou outras tecnologias mobile)
Facilidade de compartilhamento de código com a versão web do produto (que é em React)
Prazo de entrega que exigia agilidade no desenvolvimento.

2. Se for React Native, use TypeScript!

Como uma dev que precisou migrar nos 45 do segundo tempo o projeto pra TypeScript, eu digo: faça com TypeScript desde o início. Por favor (!!!)

Vai facilitar muito a manutenção do seu app, reduzir bugs bobos e tornar o onboarding de novos devs muito mais tranquilo. O que parece "trabalho extra" no começo vira economia de tempo gigante depois.

no meio da jornada..já estava alucinando

conseguimos!!

3. Defina um padrão de código e arquitetura de pastas

Isso foi algo um pouco difícil no começo, pois eu mesma tinha pouca experiência em desenvolvimento mobile, e precisei estudar bastante pra entender qual seria o melhor fluxo pra nossa realidade.

O mais importante é definir um padrão de código claro, que faça sentido pro seu projeto, e ser consistente com ele. Não precisa ser perfeito desde o início, não tem nenhum problema em evoluir conforme a equipe aprende também! Seja receptivo a sugestões e mudanças.

4. Faça uma "entrega de bastão" com outras pessoas do time

Depois de um tempo do começo do projeto, percebi que como muita coisa do app estava sendo desenvolvida somente por mim, isso gerava um sentimento de que "eu" era a única pessoa responsável pelo projeto que poderia resolver alguns pepinos depois da primeira entrega. É o famoso Bus Factor, evite ele a todo custo!

Por isso, organizei um momento onde reuni a galera, compartilhei a tela e mostrei na prática como o projeto funcionava, junto com uma documentação. O objetivo era quebrar essa barreira e incentivar todo mundo a se sentir à vontade pra mexer no app.

Minha cartolina

5. Crie uma documentação bacana

Mais uma coisa que pequei no começo do projeto (até devido ao prazo de entrega) foi a documentação. Isso acabou gerando problemas quando outros devs foram me ajudar no projeto: pela falta de documentação, ficou difícil entender algumas decisões que foram tomadas e como o código estava estruturado também, além de alguns processos que estavam só na minha cabeça. Basicamente eu me tornei a documentação, o que não é muito legal.

Como viver é aprender, hoje já tenho mais cuidado com a documentação e procuro sempre deixá-la atualizada! Recomendo fortemente que você faça o mesmo desde o início.

Um pouco da documentação que criei

6. Recomendação: utilize Expo

Eu sempre tento ir por uma abordagem pragmática das coisas (não sei se é por que sou dev PHP haha), mas considerando nosso contexto (equipe reduzida de 1-2 devs, prazo de entrega bem curto, aplicativo sem funcionalidades super complexas) foi muito fácil a decisão de usar o Expo.

Ele atende super bem e a parte do EAS (que é a cloud deles) também vai quebrar um galho caso existam pessoas no seu time com pouca experiência em desenvolvimento mobile ou sem ambiente configurado.

E agora, com os Expo Modules, cada vez mais é possível ter liberdade pra mexer com código nativo quando necessário também!

7. Fique de olho nas novas tecnologias e ferramentas

Algo muito importante é a melhoria contínua. O ecossistema React/React Native é bem dinâmico e tá sempre lançando novidades.

Fique atento às atualizações, tanto pra ver algo que você pode melhorar na sua aplicação quanto pra identificar algo que não esteja mais funcionando bem e que você pode remover ou substituir.

Reflexão final

Tooodo esse processo me ensinou que as decisões técnicas precisam sempre considerar o contexto da equipe e do negócio. O que funciona pra um projeto pode não funcionar pra outro, e tudo bem! O importante é aprender, adaptar e compartilhar o conhecimento com a galera.

Construindo Apps Local-First com Legend State no React Native

Luma Montes — Fri, 16 May 2025 09:58:25 +0000

Se você quiser ir direto para o código, esse repositório aqui tá contendo uma API e um app com Expo que implementam tudo que falei nesse artigo:

Local-First é um conceito super popular no desenvolvimento de aplicações modernas que oferece uma ótima experiência para o usuário. Na prática, é um conceito bem direto: todas as ações são "cacheadas" localmente antes de serem sincronizadas com o backend, permitindo que o app funcione mesmo offline.

Os desafios do Local-First

Implementar traz alguns desafios bem específicos:

Como monitorar o status de conectividade do usuário que fica mudando o tempo todo?
Como disparar a sincronização com o backend quando voltar online?
Vou precisar fazer todo esse gerenciamento do zero no meu projeto?

Felizmente, existem diversas soluções que facilitam a implementação do Local-First em diferentes aplicações, mas neste artigo eu vou falar um pouquinho sobre uma lib mais recente e bem legal que oferece uma solução elegante para esse problema: Legend State.

Por que Legend State?

O Legend State é extremamente rápido (dá uma olhada nos benchmarks) e se trata de uma lib de gerenciamento de estado local e remoto com um poderoso sistema de sincronização que funciona com qualquer backend.

Maaaas para ser tão rápido, o Legend State possui um conceito de "reatividade" um pouco diferente do React tradicional. Não vou entrar em muitos detalhes aqui, mas recomendo dar uma olhada na documentação oficial sobre, existe alguns conceitos novos que precisamos aprender para usar a lib da melhor forma.

Um ponto que também vale a pena mencionar é que versão recomendada atualmente pelo Legend State ainda está em beta, mas bem próximo de um lançamento oficial.

Vamos ao código!

Vamos criar um app de posts que funciona offline-first, com sincronização automática quando online. Primeiro, vamos configurar nossa store:

// store/posts.ts
import { observable } from '@legendapp/state';
import { ObservablePersistLocalStorage } from '@legendapp/state/persist-plugins/local-storage';
import { ObservablePersistMMKV } from '@legendapp/state/persist-plugins/mmkv';
import { syncedCrud } from '@legendapp/state/sync-plugins/crud';
import { Platform } from 'react-native';

export interface Post {
  id?: string;
  title: string;
  content: string;
  createdAt?: string;
  updatedAt?: string;
}

export type CreatePostInput = Pick<Post, 'title' | 'content'>;

export type CreatePostOutput = {
  status: string;
  data: Post;
  message: string;
}

const API_URL = 'http://localhost:3000/api';

const getPosts = async () => {
  const response = await fetch(`${API_URL}/posts`);
  return response.json().then(data => {
    return data.data;
  });
};

const createPost = async (input: CreatePostInput): Promise<Post> => {
  const response = await fetch(`${API_URL}/posts`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(input),
  });
  const result = await response.json();
  return result.data;
};

const updatePost = async (input: Partial<Post>) => {
  const response = await fetch(`${API_URL}/posts/${input.id}`, {
    method: 'PUT',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(input),
  });
  return response.json();
};

const deletePost = async (input: Post) => {
  await fetch(`${API_URL}/posts/${input.id}`, {
    method: 'DELETE',
  });
  return { id: input.id };
};

export const postStore$ = observable(syncedCrud<CreatePostInput, CreatePostInput, 'array'>({
  initial: [] as Record<string, Post>[],
  as: 'array',
  list: getPosts, // Aqui usamos list pois nosso endpoint retorna // um conjunto de dados. caso retornasse somente um dado, usariamos // get e não list
  create: createPost,
  update: updatePost,
  delete: deletePost,
  persist: {
    name: 'posts',
    plugin: Platform.OS === 'web' ? ObservablePersistLocalStorage : ObservablePersistMMKV,
  },
  onSaved: (data) => {
    //Quando o post é salvo no backend, recebemos a resposta aqui
    //E podemos atualizar o post no store de acordo com os dados do post salvo no backend, caso quisermos
    //Por exemplo, se quisermos atualizar o post com o id do post salvo no backend etc
    return {
      ...data.saved,
    }
  },
  retry: {
    infinite: true, // Continua tentando em caso de erro
  },
  syncMode: 'auto',
  fieldUpdatedAt: 'updatedAt',
  fieldCreatedAt: 'createdAt',
}));

Perceba que usamos o syncedCrud, um plugin pronto criado pelo Legend State que pode se conectar com qualquer backend. Com ele, basta a gente definir quais funções se conectam aos endpoints para ter toda a lógica de sincronização pronta (bem show).

O código acima já configura:

A tipagem
Os métodos CRUD que se comunicam com a API. Então o list seria o endpoint getAll do meu CRUD, e assim por diante
A persistência de dados multiplataforma (LocalStorage na web, MMKV no mobile)
O modo de sincronização automática

Implementando o componente principal

O componente principal do app mostra como usar o store e lidar com conectividade:

// App.tsx
import { useEffect, useState } from 'react';
import { View, Text, ScrollView } from 'react-native';
import { observer, use$ } from '@legendapp/state/react';
import { useObservable } from '@legendapp/state/react';
import NetInfo from '@react-native-community/netinfo';
import { syncState } from "@legendapp/state"

import { postStore$ } from 'store/posts';
import { Post } from 'types/post';
import { CreatePostForm } from './components/CreatePostForm';
import { PostCard } from './components/PostCard';

const App = observer(() => { //Adicionamos o observer para esse componente ficar verificando as mudanças 
  const connectivityStatus$ = useObservable<string>('checking');
  const posts = use$(postStore$)
  const state$ = syncState(postStore$);
  const isLoaded = state$.isLoaded.get();
  const isError = state$.error.get();
  const error = state$.error.get();

  useEffect(() => {
    const unsubscribe = NetInfo.addEventListener(state => {
      connectivityStatus$.set(state.isConnected ? 'online' : 'offline');
    });

    return () => unsubscribe();
  }, []);

  return (
    <View className="flex-1 bg-gray-50">
      <ScrollView className="flex-1 px-4 pt-12">
        <View className="mb-6">
          <Text className="text-3xl font-bold text-gray-900">Posts</Text>
        </View>

        <ConnectionStatus status={connectivityStatus$.get()} />

        {isError && (
          <View className="mb-6 rounded-lg bg-red-100 p-4">
            <Text className="text-sm font-medium text-red-800">Error {error?.message}</Text>
          </View>
        )}

        {!isLoaded && (
          <View className="mb-6 rounded-lg bg-blue-100 p-4">
            <Text className="text-sm font-medium text-blue-800">Carregando posts...</Text>
          </View>
        )}

        {Object.entries(posts || {}).map(([id, post]) => (
          <PostCard key={id} post={{ ...post, id }} />
        ))}

        {posts.length === 0 && (
          <View className="mb-6 rounded-lg bg-gray-100 p-4">
            <Text className="text-sm font-medium text-gray-800">Nenhum post encontrado</Text>
          </View>
        )}
      </ScrollView>
    </View>
  );
});

export default App;

O componente acima:

Monitora o status de conectividade com o NetInfo
Exibe um indicador visual para informar o usuário se está online ou offline
Mostra estados de loading e erro conforme necessário
Renderiza a lista de posts, já usando nossa store!

E agora para criar, atualizar e deletar os registros?

Basta chamarmos a nossa store e manipularmos diretamente o nosso array: dando um push para criar, um set para atualizar e um delete para deletar.

Por exemplo, o código no componente de card do post ficaria assim:

const PostCard = observer(({ post }: { post: Post }) => {
  const postId = post.id;
  const handleUpdate = () => {
    postStore$[postId].set({
      ...postStore$[postId].get(),
      title,
      content,
    }) //Aqui automaticamente será chamado o endpoint de PUT
  };

  const handleDelete = () => {
    postStore$[postId].delete(); //Automaticamente sera chamado o endpoint de delete que configuramos
  };

  ...resto do código
  };
});

E o código no componente de criação do post:

const CreatePostForm = observer(() => {
  const [title, setTitle] = useState('');
  const [content, setContent] = useState('');

  const handleSubmit = () => {
    const randomId = Date.now().toString(); //Adiciona um id aleatório para o post, para salvar no local (e depois salvar no backend)
    if (title && content) {
      const input = { id: randomId, title, content, author: 'Lumix'};
      postStore$.push(input); //Aqui adicionamos na nossa store, e automaticamente será chamado o endpoint POST
      setTitle('');
      setContent('');
    }
  };

  return (
    ...resto do código
  );
});

Prontinho! Nosso CRUD está pronto, com sincronização de dados offline que se conecta automaticamente com nosso backend ao mudar o status de conectividade do usuário :)

Conseguimos implementar:

Persistência Cross-Platform:
- Web: LocalStorage
- Mobile: MMKV
Sincronização Automática:
- Mudanças são salvas localmente primeiro
- Sincronização automática quando online
UI Responsiva:
- Feedback imediato para o usuário
- Indicador de status de conexão
- Loading e error states
CRUD Completo:
- Create: Cria posts mesmo offline
- Read: Lista posts do cache local
- Update: Atualiza posts com sync automático
- Delete: Remove posts com sync quando online

Menção honrosa: Hook onSaved

Um recurso interessante do syncedCrud é o hook onSaved, que nos permite receber e processar a resposta do backend após uma operação ser sincronizada. No nosso exemplo:

onSaved: (data) => {
  //Quando o post é salvo no backend, recebemos a resposta aqui
  //E podemos atualizar o post no store de acordo com os dados do post salvo no backend
  return {
    ...data.saved,
  }
}

Isso é útil para casos onde o backend pode adicionar informações extras ao nosso objeto (como IDs gerados pelo banco, timestamps atualizados, etc).

Conclusão

Com o Legend State, implementamos um app Local-First robusto com poucas linhas de código. A biblioteca cuida de toda a complexidade de sincronização, persistência e gerenciamento de estado, adiantando bastante o tempo de desenvolvimento.

Recursos úteis:

Construindo um monolito moderno com Inertia.js

Luma Montes — Fri, 03 Jan 2025 20:31:56 +0000

Recentemente tive uma experiência com Inertia Js em um projeto, e fiquei impressionada com a facilidade que foi o desenvolvimento! Neste artigo, vou falar um pouquinho sobre como o Inertia funciona e seus benefícios.

O que é o Inertia.js?

O Inertia JS é uma nova abordagem criada pra facilitar o desenvolvimento de monolitos modernos. Ele tem uma forte relação com o ecossistema Laravel, mas também pode ser usado em outros frameworks de backend. Um projeto com Inertia.js é bem parecido com os projetos em PHP, a diferença é que o frontend agora é em React (ou Vue). O inertia.js atua fazendo a comunicação entre o seu frontend e seu backend, substituindo a necessidade por uma API, por exemplo.

Por que usar o Inertia.js?

Seu objetivo de negócio e o seu time são alguns dos pontos a levar em consideração! Em projetos onde os times de frontend e backend são separados ou há integração entre diferentes negócios ou empresas, faz sentido dividir o sistema em serviços ou projetos independentes.

Em contrapartida, um só time com poucos desenvolvedores que precisariam ser multidisciplinares, trabalhando tanto no código frontend quando backend o tempo todo, fez bastante sentido em utilizar o inertia pra entregar o projeto sem grandes complexidades que os microserviços trazem.

Como funciona?

O Inertia.js elimina a necessidade de uma API tradicional. Você pode enviar dados do backend diretamente para o frontend como parâmetros em uma resposta, e o frontend usa esses dados para renderizar componentes. Para realizar a instalação, você pode seguir os passos da documentação:https://inertiajs.com/server-side-setup

Aqui adicionei um exemplo simples:

Definição de rota:

// web.php
Route::get('/books', [BooksController::class, 'index']);

Criação de lógica no controller:

//BooksController.php

namespace App\Http\Controllers;

use App\Models\Book;
use Inertia\Inertia;

class BooksController extends Controller
{
    public function index()
    {
        $books = Book::all();

        return Inertia::render('Books/Index', [
            'books' => $books
        ]);
    }
}

Renderização da sua view usando React e Typescript:

// resources/js/Pages/Books/Index.tsx
import { usePage } from '@inertiajs/react';

type Book = {
    id: number;
    title: string;
};

export default function BooksIndex() {
    const { books } = usePage().props;

    return (
        <div>
            {books.map((book: Book) => (
                <div key={book.id}>
                    {book.title}
                </div>
            ))}
        </div>
    );
}

E pronto! Esse é um exemplo simples do funcionamento do inertia, quem já vem do desenvolvimento em PHP percebe que é bem parecido com as blades do PHP (tirando o fato de ser React/Vue).

Nesse exemplo acima, o hook usePage do Inertia é usado pra puxar as informações que mandamos como lá no controller. Além disso, alguns dos principais utilitários disponíveis são:

useRemember: Armazena dados entre navegações de página.
WhenVisible: Componente usado como forma de só carregar dados quando um elemento se torna vísivel na página
Deferred: Permite você adie o carragamento de determinados nados da ágina até depois da renderização inicial, especialment usando em casos onde parte dos dados não são imediatamente necessárias no primeiro carregamento
Link: Componente usado para navegação, similar ao do React Router

Conclusão

Logicamente, tudo depende dos requisitos do seu projeto e do seu time. Mas o Inertia é uma ótima ferramenta que vem crescendo e se desenvolvendo cada vez mais no ecossistema laravel, uma ótima pedida pra projetos monolitos com PHP e com frameworks modernos como React/Vue para trazer uma melhor experiência para os usuários. A seguir o link da documentação, que foi base para este artigo, recomendo a leitura para conhecer mais sobre o Inertia:

https://inertiajs.com/

Introdução ao framework Astro

Luma Montes — Sat, 18 May 2024 02:27:42 +0000

Nos últimos tempos, ouvi falar bastante sobre o Astro! Um case recente que achei bem interessante foi a versão lite do site de noticías americano NBC news, que foi criado usando esse framework com a finalidade de ser bem mais performático e acessível em situações de calamidade.

Mas afinal, o que é Astro?

Astro, segundo a própria documentação, é um framework web "tudo em um" para criação de websites rápidos, focados em conteúdo.
Ele utiliza a estratégia de MPA(Multi Page App), em contraste com a estratégia de SPA(Single Page App) utilizada por frameworks como Next, Vue, Svelte, etc. Isso significa que ele irá possuir múltiplas páginas HTML e dará preferência, sempre que possível, a rendereração de conteúdo no servidor, ao invés de renderizar no cliente, como é feito em SPAs.

A estratégia MPA é uma abordagem tradicional e usada por diversas linguagens, como por exemplo o PHP. Mas diferente do PHP, onde é utilizado o PHP no servidor e Javascript no navegador, o Astro trás uma abordagem única onde o Javascript é utilizado tanto no servidor quando no navegador.

Isso torna o seu site bem mais rápido e performático. Logo, sites que possuem bastante conteúdo estático como blogs, sites de notícias, portfólios, etc, são os principais candidatos a se beneficiar com o uso do Astro.

Porque Astro?

O Astro possui uma boa experiência de desenvolvimento, com uma linguagem relativamente simples e conceitos bem famíliares. A ideia deles é que qualquer pessoa que tenha um pouco de contato com HTML, CSS e Javascript consiga criar um projeto rapidamente.

Além de possuir uma API própria para criação de componentes utilizando arquivos .astro, o framework oferece diversas integrações com outras ferramentas, como React, Vue, Svelte, Solid e mais. Isso significa que dentro de um componente estático .astro`, voce pode importar um componente em React, por exemplo. Isso é bem interessante, pois permite que você utilize o Astro em conjunto com outras ferramentas, sem precisar se prender a uma única tecnologia, trazendo a superfície o conceito de UI agnóstica desse framework.

No entanto, um dos grandes destaques realmente é a performance. Com o conceito de zero Javascript por padrão e renderização de conteúdo com preferência no servidor, utilizando a arquitetura MPA, o seu site será leve e rápido. Fazendo uma comparação direta do mesmo blog feito com Astro e com o Next.js por exemplo, foi identificado um carregamento 40% mais rápido e com 90% menos Javascript.

Outros principais conceitos que podemos destacar:

Sintaxe de componentes própria(meucomponente.astro)
Roteamento baseado em arquivos
Manipulação de assets, processo de build, bundling, otimizações, busca de dados e mais.

Por fim, possui uma boa documentação e uma comunidade bem ativa e em crescimento.

Caso voce queira saber mais sobre o Astro, recomendo que voce leia a documentação oficial, que é bem completa e possui diversos exemplos e tutoriais, e serviu como base para esse post :)

https://docs.astro.build/pt-br/getting-started/

Por lá, também é possível encontrar diversos templates que podem ajudar a entender melhor o framework ou até mesmo já servir de base para o seu próximo projeto. ✨

Gerenciamento de estados de forma minimalista no React Native com Jotai

Luma Montes — Sat, 09 Mar 2024 17:12:34 +0000

Nesse artigo, vou falar sobre o Jotai, uma biblioteca de gerenciamento de estados globais para React. Vou explicar o que é, como instalar e como usar, com exemplos práticos.

O que é Jotai?

Jotai é uma biblioteca de gerenciamento de estados globais para React, destacando-se pela simplicidade e facilidade de uso. Ela é capaz de escalar desde aplicações simples até aquelas com estados mais complexos, graças à sua flexibilidade e performance. Com apenas 2kb, a API principal é extremamente leve, contribuindo para a eficiência da biblioteca. A Jotai adota uma abordagem 'atômica' para o gerenciamento de estados globais.

Nesse exemplo vou estar utilizando Jotai em React Native com Typescript, porém o Jotai é compatível com outros frameworks como Next.js, Gatsby, Remix e Waku.

Instalação

Para instalar o Jotai, basta rodar o comando no seu terminal do seu projeto React Native:

npm install jotai

yarn add jotai

pnpm add jotai

Exemplo

O Jotai tem uma estrutura definida por átomos, que são os estados. Pra qualquer estado ou variável global que você quiser criar, você vai criar um átomo.

No meu exemplo, digamos que eu tenha um app financeiro e eu queira 2 estados globais, que vou precisar acessar em vários lugares do app:

um número inteiro que irá armazenar o saldo do usuário.
um booleano que vai controlar se o saldo financeiro está visível ou não.

Logo, eu vou criar 2 átomos, um para cada estado que eu quero armazenar. Uma boa prática é criar um arquivo separado somente para a criação dos átomos, para que fique mais organizado. No meu exemplo, na raiz do projeto mesmo irei criar um arquivo chamado Atoms.ts que vai conter todos os átomos.


import { atom } from 'jotai';

export const balanceAtom = atom(0);
export const isBalanceVisibleAtom = atom(false);

Conforme o exemplo acima, usei a função atom do Jotai para criar um átomo que representa um estado global.

Essa função atom recebe um parâmetro que é o valor inicial do átomo, e dependendo do tipo desse valor, o Jotai já consegue inferir o tipo do átomo.

Por exemplo, no meu caso, o átomo isBalanceVisibleAtom é um booleano, então eu passei um false como valor inicial. E o átomo balanceAtom é um número, então eu passei 0 como valor inicial.

E é isso! Agora eu posso chamar esses átomos em qualquer lugar do meu app, para visualizar e/ou alterar o valor dos mesmos utilizando o hook useAtom do Jotai.

Primeiro, vou criar um componente que irá exibir o saldo do usuário e um botão para adicionar um valor de 10 ao saldo.


import { View, Text, Button } from 'react-native';
import { useAtom } from 'jotai';
import { balanceAtom } from '@/Atoms';

export default function Balance(){
    const [balance, setBalance] = useAtom(balanceAtom);
    return (
        <View>
            <Text>Saldo: {balance}</Text>
            <Button title="Adicionar 10" onPress={() => setBalance((prev) => prev + 10)} /> 
        </View>
    )
}

Conforme o exemplo acima, utilizamos o hook useAtom do Jotai, que irá retornar duas funções que são parecidas com o useState do React. A primeira função será o valor desse átomo, e a segunda é uma função pra atualizar o valor desse átomo.

Nesse caso, quero exibir em tela o saldo do usuário, então no useAtom passei como parâmetro o balanceAtom que é o átomo que defini para representar esse estado.

useAtom(balanceAtom);

E como retorno, eu recebo o valor do saldo e a função para atualizar o saldo.

const [balance, setBalance] = useAtom(balanceAtom);

Agora, vamos criar um componente de header que irá exibir um botão para mostrar ou esconder o saldo do usuário.


import {View, Text, Button} from 'react-native';
import { useAtom } from 'jotai';
import { isBalanceVisibleAtom } from '@/Atoms';

export default funcion Header(){
    const [isBalanceVisible, setIsBalanceVisible] = useAtom(isBalanceVisibleAtom);
    return (
        <View>
            <Text>Bem vindo!</Text>
            <Button title="Mostrar saldo" onPress={() => setIsBalanceVisible(!isBalanceVisible)} />
        </View>
    )
}

Agora, posso atualizar o componente Balance para que ele só seja exibido se o saldo estiver visível.

import { View, Text, Button } from 'react-native';
import { useAtom } from 'jotai';
import { balanceAtom, isBalanceVisibleAtom } from '@/Atoms';


export default function Balance(){
    const [balance, setBalance] = useAtom(balanceAtom);
    const [isBalanceVisible] = useAtom(isBalanceVisibleAtom);
    return (
            <View>
                <Text>Saldo: {isBalanceVisible ? balance : '***'}</Text>
                <Button title="Adicionar 10" onPress={() => setBalance((prev) => prev + 10)} />
            </View>
    )
}

Dessa forma, o saldo só será exibido se o usuário clicar no botão "Mostrar saldo" do componente Header.

E é isso! Agora eu tenho 2 estados globais que posso acessar e posso atualizar de qualquer lugar do meu app. E o melhor de tudo, o Jotai já cuida de atualizar todos os componentes que estão usando esses átomos, lidando por trás dos panos otimização, memorização, e re-renders desnecessários.

Conclusão

o Jotai é uma biblioteca fantástica que simplifica muito o gerenciamento de estados do React. Além dos exemplos que mostrei, o Jotai tem várias outras funcionalidades que podem ser muito úteis, como um pacote responsável por fazer cache de átomos, fazer transições de estados, integração com outras ferramentas como React Query, e muito mais.

Recomendo dar uma olhada na documentação oficial para ver mais detalhes e exemplos de uso: https://jotai.org/ 🚀

Fluxo de autenticação no React Native usando Expo Router

Luma Montes — Sun, 18 Feb 2024 05:33:32 +0000

Quem já trabalhou com rotas com Expo ou React Native, sabe que o React Navigation é a forma padrão de lidar com navegação! No entanto, conforme mais telas você vai criando no seu app, o código utilizado pode ficar bem grande, com processos manuais que precisam de muitas linhas de código para serem feitos. Logo, o time do Expo lançou uma novidade: Expo Router, uma alternativa ao React Navigation para roteamento e navegação com React Native.

Esse post irá mostrar como criar um fluxo de autenticação com Expo Router no seu app React Native.

Índice

Principais funcionalidades do Expo Router:
Pré-requisitos
Exemplo de código
- 1 - Crie um contexto de autenticação
- 2 - Adicione o arquivo app/_layout.tsx
- 3 - Crie a tela de login
- 4 - Adicione a lógica de autenticação no arquivo app/(auth)/_layout.tsx
Conclusão

generated with Summaryze Forem 🌱

Principais funcionalidades do Expo Router:

Nativo: Construído em cima do React Navigation, a navegação do Expo Router é nativa e otimizada.
Compartilhável: Toda tela do seu aplicativo é automaticamente configurada com deep linking. Tornando qualquer rota do seu aplicativo compartilhável com links, como por exemplo, um link de redirecionamento de uma notificação, não sendo necessário configurar manualmente quais telas são acessíveis por links.
Offline-first: Os aplicativos são armazenados em cache e executados de forma offline first, com atualizações automáticas quando você publica uma nova versão.

O Expo Router trás um conceito de file based routing, ou seja, as rotas da aplicação refletem a estrutura dos arquivos criados na pasta /app. Parecido, por exemplo, com a estrutura do Next.js.

Quando um arquivo é criado na pasta app, automaticamente se torna uma rota no app. Logo, diferentemente do React Navigation, todas as stacks (ou rotas) do seu app já ficam publicas e disponíveis para navegação! Além disso, as navegações para diferentes telas podem ser feitas usando um elemento <Link href='/nome-da-rota', por exemplo. bem parecido com o que fazemos na web. Você pode usar um router.replace('nome-da-rota') para definir globalmente o redirecionamento de rota, além de rotas dinâmicas, criação de grupos de rotas e muito mais. 🤯

Pré-requisitos

Para o exemplo a seguir, você pode clonar o projeto para reproduzir o exemplo.



git clone git@github.com:lumamontes/expo-router-auth.git

Instale as dependências do projeto:



npx expo install

E rode o projeto:



npx expo start

Mas, caso queira criar um projeto do zero, você pode seguir os passos originais do Expo Router.

Exemplo de código

Agora, vamos a um exemplo no código! Vamos implementar um fluxo de autenticação utilizando o Expo Router para navegação. Vamos analisar a estrutura do projeto:

Alguns pontos chaves para entender o Expo Router:

Todos os arquivos que estão na pasta /app serão rotas (com exceção de arquivos "especiais", que irei comentar abaixo!)
_layout.tsx: O expo router possibilita a criação de Layout routes, elementos que são compartilhados entre diversas telas, como uma header. No caso do arquivo app/_layout.tsx, ele é um layout que será compartilhado entre todas as telas dentro da pasta /app.
Pastas (auth) e (tags): são grupos de rotas do Expo Router, que são usados para organizar as rotas do app. Você pode adicionar quantos grupos quiser. Grupos também são bons para organizar seções do app. No exemplo a seguir, temos app/(auth) que irá ter as telas para usuários autenticados. Um ponto interessante é que os grupos não afetam a url, ou seja, um arquivo localizado na pasta app/(auth)/nome-do-arquivo.tsx não terá a url app/(auth)/nome-do-arquivo, mas sim app/nome-do-arquivo.
ctx.tsx: é um contexto de autenticação, que irá centralizar algumas informações globais como a sessão do usuário, a função de logar e deslogar.
+not-found.tsx: é uma rota que será acessada quando nenhuma outra rota for encontrada.

Logo, o nosso app irá possui duas camadas:

Rotas para usuários autenticados (todo o conteúdo do grupo (auth))
Rotas para usuários não autenticados (somente a tela de login)

Para fazer essa separação entre a camada de usuários autenticados e não autenticados, é possível criar um contexto que vai definir essas regras de negócio:

1 - Crie um contexto de autenticação

Esse contexto irá centralizar algumas informações e lógicas globais como a sessão do usuário, a função de signIn e signOut.



iimport React from "react";
import { useStorageState } from "./useStorageState";

const AuthContext = React.createContext<{
  signIn: () => void;
  signOut: () => void;
  session?: string | null;
  isLoading: boolean;
}>({
  signIn: () => null,
  signOut: () => null,
  session: null,
  isLoading: false,
});

// This hook can be used to access the user info.
export function useSession() {
  const value = React.useContext(AuthContext);
  return value;
}

export function SessionProvider(props: React.PropsWithChildren) {
  const [[isLoading, session], setSession] = useStorageState("session");
  return (
    <AuthContext.Provider
      value={{
        signIn: () => {
          // Add your login logic here
          // For example purposes, we'll just set a fake session in storage
          setSession("John Doe");
        },
        signOut: () => {
          setSession(null);
        },
        session,
        isLoading,
      }}
    >
      {props.children}
    </AuthContext.Provider>
  );
}

A função signIn irá salvar a sessão do usuário, nesse caso, uma simples string 'John Doe', e a função signOut irá remover a sessão alterando esse valor para null.

Para finalidade de testes, a função signIn não irá ter nenhum tipo de validação, sempre que ela for chamada, o usuário será autenticado. No entanto, em um app real, você pode adicionar a lógica de login do seu app fazendo uma requisição para uma API, por exemplo.

Um ponto importante é que iremos salvar essas informações de sessão do usuário no storage do dispositivo, para que o usuário não precise logar toda vez que abrir o app.

Para isso, utilizaremos o hook useStorageState que retornar um estado e uma função para alterar esse estado, salvar e recuperar as informações do storage do dispositivo utilizando a biblioteca expo-secure-store.

Esse hook é composto por três funções:

A função useAsyncState irá retornar um estado e uma função para alterar esse estado, mas com um estado inicial de loading, que será true, e o valor inicial, que será null.



import * as SecureStore from "expo-secure-store";
import * as React from "react";
import { Platform } from "react-native";

type UseStateHook<T> = [[boolean, T | null], (value: T | null) => void];

function useAsyncState<T>(
  initialValue: [boolean, T | null] = [true, null]
): UseStateHook<T> {
  return React.useReducer(
    (
      state: [boolean, T | null],
      action: T | null = null
    ): [boolean, T | null] => [false, action],
    initialValue
  ) as UseStateHook<T>;
}

setStorageItemAsync: que irá salvar ou deletar um item no storage do dispositivo, dependendo do valor passado.



export async function setStorageItemAsync(key: string, value: string | null) {
  if (value == null) {
    await SecureStore.deleteItemAsync(key);
  } else {
    await SecureStore.setItemAsync(key, value);
  }
}

useStorageState: que irá retornar um estado e uma função para alterar esse estado, salvando e recuperando as informações do storage do dispositivo utilizando a biblioteca expo-secure-store.



export function useStorageState(key: string): UseStateHook<string> {
  const [state, setState] = useAsyncState<string>();

  React.useEffect(() => {
    SecureStore.getItemAsync(key).then((value) => {
      setState(value);
    });
  }, [key]);

  const setValue = React.useCallback(
    (value: string | null) => {
      setState(value);
      setStorageItemAsync(key, value);
    },
    [key]
  );

  return [state, setValue];
}

Logo, se eu usar o hook dessa forma: useStorageState('session'), ele irá retornar: isLoading, session e setSession.

Mas se eu usasse dessa forma: useStorageState('user'), ele irá retornar: isLoading, user e setUser, por exemplo.

Podemos então entender que o useStorageState é um hook genérico que irá retornar um estado e uma função para alterar esse estado, salvando e recuperando as informações do storage do dispositivo utilizando a biblioteca expo-secure-store.

2 - Adicione o arquivo app/_layout.tsx

Esse arquivo é um layout que será compartilhado entre todas as telas do app. Nele, podemos:

- Definir a rota inicial do app



export const unstable_settings = {
  initialRouteName: "login",
};

Essa simples linha de código irá garantir que a rota inicial do nosso app será sempre 'login', ou seja, o componente presente no arquivo de login.tsx!

- Adicionar o nosso contexto por volta de todo o seu app

Ele irá apenas retornar o children, que será a stack do grupo (auth) ou a tela de login, dependendo se o usuário está autenticado ou não. Para isso, usaremos o <Slot> do Expo Router, que é um elemento que irá renderizar o "children" da rota atual:



import { Slot } from "expo-router";
import { SessionProvider } from "./ctx";

export default function RootLayoutNav() {
  return (
    <SessionProvider>
      <Slot />
    </SessionProvider>
  );
}

3 - Crie a tela de login

Na tela de login, que será o arquivo app/login.tsx, você pode adicionar a lógica de login do seu app, como um formulário de email e senha. No nosso caso, vamos somente um botão que irá logar o usuário no app.



export default function Login() {
  const { signIn } = useSession();
  const handleLogin = () => {
    signIn();
    //Antes de navegar, tenha certeza de que o usuário está autenticado
    router.replace("/");
  };

  return (
    <View>
      <Button title="Login" onPress={handleLogin} />
    </View>
  );
}

Isso irá redirecionar para (auth)/\_layout.tsx!

4 - Adicione a lógica de autenticação no arquivo `app/(auth)/\_layout.tsx`

Esse arquivo é um layout que será compartilhado entre todas as telas do app no grupo (auth), ou seja, todas as telas que precisam de autenticação para serem acessadas. Nele, podemos adicionar a lógica de autenticação do app:

Se o usuário não possuir sessão, redirecionar para a tela de login
Caso o usuário tenha sessão, retornar a stack do grupo (tabs), que contém o restante das telas do app.



const { session } = useSession();

if (!session) {
  return <Redirect href="/login" />;
}

return (
  <Stack>
    <Stack.Screen name="(tabs)" options={{ headerShown: false }} />

    <Stack.Screen name="modal" options={{ presentation: "modal" }} />
  </Stack>
);

Assim, ao clicar para login e ser redirecionado com sucesso, o usuário irá ter acesso a tela app/(auth)/(tabs)/index.tsx!

E caso o usuário não esteja autenticado, ele será redirecionado para a tela de login, completando um fluxo básico de autenticação.

Conclusão

Fazendo um comparativo com React Navigation, acredito que o Expo Router é bem acessível e fácil de entender, principalmente pra quem vem do desenvolvimento de frontend web.

Onde no React Navigation, várias funcionalidades eram feitas de forma manual, como a criação das rotas, a configuração de deep linking, entre outras, esses processos super importantes são feitos já automaticamente pelo Expo Router, deixando o código bem mais limpo. Pelo fato de ser file based routing, a estrutura do projeto fica bem mais organizada, e a navegação entre telas é bem mais simples, com a utilização do elemento <Link href='/nome-da-rota'.

No geral, acredito que o Expo Router é uma ótima ferramenta para quem está começando a desenvolver apps com react native, ou para quem já tem experiência com react native e quer otimizar o tempo de desenvolvimento e manter uma navegação de fácil implementação. Estarei utilizando nos meus novos projetos com Expo 🚀

Segue o link do projeto no github, caso queira testar o código:

Expo Router Auth

Forem: Luma Montes

Migração de dados entre serviços: estratégias, riscos e trade-offs

Estratégias

Desafios práticos que você vai enfrentar

Dados faltando ou inconsistentes

Enriquecimento de dados

Trade-offs técnicos

Velocidade vs correção

Jupyter Notebook vs CLI

Migrar tudo vs migrar só o essencial

Processar tudo de uma vez vs em lotes

Conclusão

Usando Guard/Wrapper components como alternativa a condições ternárias no React

Melhorando o código

A versão genérica

Antes:

Depois:

Versão menos genérica (e mais declarativa)

A implementação:

Pontos Positivos

Conditional Wrappers e outras arquiteturas

1. Conditional Wrappers

2. Role-Based Components

3. Feature Flag Components

Quando usar (e quando NÃO usar)

Use wrapper components quando:

Continue tranquilamente com ternários quando:

Dicas práticas para implementação!

1. Comece simples

2. Questione-se sempre: "Isso realmente está melhor?"

O que eu aprendi liderando tecnicamente a criação de um aplicativo de comunicação escolar

1. Como decidir a stack inicial de um produto mobile?

2. Se for React Native, use TypeScript!

3. Defina um padrão de código e arquitetura de pastas

4. Faça uma "entrega de bastão" com outras pessoas do time

5. Crie uma documentação bacana

6. Recomendação: utilize Expo

7. Fique de olho nas novas tecnologias e ferramentas

Reflexão final

Construindo Apps Local-First com Legend State no React Native

Os desafios do Local-First

Por que Legend State?

Vamos ao código!

Implementando o componente principal

E agora para criar, atualizar e deletar os registros?

Menção honrosa: Hook onSaved

Conclusão

Construindo um monolito moderno com Inertia.js

O que é o Inertia.js?

Por que usar o Inertia.js?

Como funciona?

Conclusão

Introdução ao framework Astro

Mas afinal, o que é Astro?

Porque Astro?

Gerenciamento de estados de forma minimalista no React Native com Jotai

O que é Jotai?

Instalação

Exemplo

Conclusão

Fluxo de autenticação no React Native usando Expo Router

Índice

generated with Summaryze Forem 🌱

Principais funcionalidades do Expo Router:

Pré-requisitos

Exemplo de código

1 - Crie um contexto de autenticação

2 - Adicione o arquivo app/_layout.tsx

- Definir a rota inicial do app

- Adicionar o nosso contexto por volta de todo o seu app

3 - Crie a tela de login

4 - Adicione a lógica de autenticação no arquivo app/(auth)/\_layout.tsx

Conclusão

4 - Adicione a lógica de autenticação no arquivo `app/(auth)/\_layout.tsx`