React para uma dev back-end

No dia a dia do meu trabalho atuo com muito back-end usando C# e .NET, tanto dando manutenção e criando novas features quando criando soluções do zero - agora posso dizer isso, já criei minha primeira API do zerinho! Também tenho alguma familiaridade com Javascript e Typescript e CSS, então não vou entrar nesses pormenores aqui, vou focar mais na arquitetura e nas features do React e o que encontrei de novidade pra mim. Embora seja back-ender de coração, sou contratada como fullstack e eventualmente preciso fazer algo relacionado a front-end. Já criei algumas features e fiz pequenos ajustes em React e Vue mas dessa vez recebi uma demanda diferente: criar uma tela do zero pra um novo produto. Uma tela simples, mas ainda cheia de regras de negócio importantes a serem seguidas. Como a demanda se divide em front e back, optei por deixar o back o mais redondo possível para só então começar o front - procrastinando a tarefa mais difícil na cara de pau. Quando chegou a hora de começar o front, peguei alguns projetos como referência, baixei o boilerplate do projeto inicial e deu branco: por onde começo? Criando a UI Resolvi seguir uma estratégia top-down na divisão e criação dos componentes. Também optei por criar todo o esqueleto da página para só no final adicionar lógica e refinar os estilos caso necessário (spoiler: foi necessário). Essa parte foi relativamente mais tranquila porque usei componentes do design system do banco, embora eu prefira criar tudo na mão preciso confessar que foi uma mão na roda - pelo menos os que não precisei estilizar. Na hora de adicionar a lógica, tendo alguns projetos como base, optei por manter o máximo possível os métodos separados do componente em si, então minha estrutura ficou dessa forma para cada componente: Criado o esqueleto, criei os services que vão se comunicar com a API utilizando Axios. Para isso criei as interfaces de parâmetros e objetos a serem recebidos e um arquivo de config do Axios exportando a configuração com a URL base da API. Implementei a princípio somente os services que iriam obter os dados para apagar os mocks e começar a trabalhar com dados reais na tela, deixando os services de post e put para um segundo momento. Estado Aqui vale mencionar alguns conceitos importantes relacionados ao front-end e à forma como o React lida com o estado da aplicação: Estado é uma representação dos dados em um componente, como o conteúdo de um formulário ou um item selecionado. Gerenciamento de estado: ajuda a controlar esses dados entre os componentes quando é necessário o compartilhamento entre eles, evitando que sejam passados como propriedades por diversos componentes da árvore (o chamado prop drilling). O React utiliza um hook chamado useState para gerenciar o estado local, ou seja, dentro de um componente. Já para o estado global, temos a ContextAPI do próprio React ou o Redux, que oferece opções mais robustas e complexas. Como preciso de dados de diversos componentes para montar uma requisição para a API, decidi criar esse estado global com os valores iniciais vazios. Para isso, usei a ContextAPI já que se trata de uma aplicação relativamente simples. Para fins de exemplo vou criar o gerenciamento de estado para um usuário: 1- Criar o contexto utilizando o hook useContext: const UserContext = createContext(); export const useUser = () => useContext(UserContext); 2- Criar um provider, que vai envolver os outros componentes e fornecer o estado do contexto para eles. Aqui o estado inicial foi definido como vazio: export const UserProvider = ({ children }) => { const [user, setUser] = useState(null); return ( {children} ); }; 3- Envolver a aplicação com o provider, para que todos os componentes tenham acesso ao contexto: const App = () => ( // Todos os elementos da aplicação ficam dentro do provider ); ReactDOM.render(, document.getElementById('root')); Com esses 3 passos, é possível então consumir o contexto: const UserProfile = () => { const { user, setUser } = useUser(); const handleLogin = () => { setUser({ name: 'Exemplo', email: 'exemplo@email.com' }); }; return ( {user ? ( Bem-vindo, {user.name} Email: {user.email} ) : ( Login )} ); }; Repare que aqui foi utilizado um ternário para definir se vai ser exibida a div com as boas vindas ao usuário ou o botão de login. Outra forma possível seria utilizar o operador &&: return ( {user && ( Bem-vindo, {user.name} Email: {user.email} ); ); Nessa segunda forma, se o user não estivesse setado, nada seria exibido. É importante não utilizar números no lado esquerdo do operador &&, apenas comparações ou valores que podem ser convertidos em booleanos (por exemplo, se existe um user). Listas Para exibir os elementos de um array, deve-se usar as fu

Jun 14, 2025 - 02:40

No dia a dia do meu trabalho atuo com muito back-end usando C# e .NET, tanto dando manutenção e criando novas features quando criando soluções do zero - agora posso dizer isso, já criei minha primeira API do zerinho! Também tenho alguma familiaridade com Javascript e Typescript e CSS, então não vou entrar nesses pormenores aqui, vou focar mais na arquitetura e nas features do React e o que encontrei de novidade pra mim.

Embora seja back-ender de coração, sou contratada como fullstack e eventualmente preciso fazer algo relacionado a front-end. Já criei algumas features e fiz pequenos ajustes em React e Vue mas dessa vez recebi uma demanda diferente: criar uma tela do zero pra um novo produto. Uma tela simples, mas ainda cheia de regras de negócio importantes a serem seguidas.

Como a demanda se divide em front e back, optei por deixar o back o mais redondo possível para só então começar o front - procrastinando a tarefa mais difícil na cara de pau.

Quando chegou a hora de começar o front, peguei alguns projetos como referência, baixei o boilerplate do projeto inicial e deu branco: por onde começo?

Criando a UI

Resolvi seguir uma estratégia top-down na divisão e criação dos componentes. Também optei por criar todo o esqueleto da página para só no final adicionar lógica e refinar os estilos caso necessário (spoiler: foi necessário). Essa parte foi relativamente mais tranquila porque usei componentes do design system do banco, embora eu prefira criar tudo na mão preciso confessar que foi uma mão na roda - pelo menos os que não precisei estilizar.

Na hora de adicionar a lógica, tendo alguns projetos como base, optei por manter o máximo possível os métodos separados do componente em si, então minha estrutura ficou dessa forma para cada componente:

Criado o esqueleto, criei os services que vão se comunicar com a API utilizando Axios. Para isso criei as interfaces de parâmetros e objetos a serem recebidos e um arquivo de config do Axios exportando a configuração com a URL base da API. Implementei a princípio somente os services que iriam obter os dados para apagar os mocks e começar a trabalhar com dados reais na tela, deixando os services de post e put para um segundo momento.

Estado

Aqui vale mencionar alguns conceitos importantes relacionados ao front-end e à forma como o React lida com o estado da aplicação:

Estado é uma representação dos dados em um componente, como o conteúdo de um formulário ou um item selecionado.
Gerenciamento de estado: ajuda a controlar esses dados entre os componentes quando é necessário o compartilhamento entre eles, evitando que sejam passados como propriedades por diversos componentes da árvore (o chamado prop drilling).
O React utiliza um hook chamado useState para gerenciar o estado local, ou seja, dentro de um componente. Já para o estado global, temos a ContextAPI do próprio React ou o Redux, que oferece opções mais robustas e complexas.

Como preciso de dados de diversos componentes para montar uma requisição para a API, decidi criar esse estado global com os valores iniciais vazios. Para isso, usei a ContextAPI já que se trata de uma aplicação relativamente simples.

Para fins de exemplo vou criar o gerenciamento de estado para um usuário:
1- Criar o contexto utilizando o hook useContext:

const UserContext = createContext();

export const useUser = () => useContext(UserContext);

2- Criar um provider, que vai envolver os outros componentes e fornecer o estado do contexto para eles. Aqui o estado inicial foi definido como vazio:

export const UserProvider = ({ children }) => {
  const [user, setUser] = useState(null);

  return (
    
      {children}
    
  );
};

3- Envolver a aplicação com o provider, para que todos os componentes tenham acesso ao contexto:

const App = () => (
  
     // Todos os elementos da aplicação ficam dentro do provider
  
);

ReactDOM.render(, document.getElementById('root'));

Com esses 3 passos, é possível então consumir o contexto:

const UserProfile = () => {
  const { user, setUser } = useUser();

  const handleLogin = () => {
    setUser({ name: 'Exemplo', email: 'exemplo@email.com' });
  };

  return (
    
      {user ? (
        
          Bem-vindo, {user.name}
          Email: {user.email}
        
      ) : (
        
      )}
    
  );
};

Repare que aqui foi utilizado um ternário para definir se vai ser exibida a div com as boas vindas ao usuário ou o botão de login. Outra forma possível seria utilizar o operador &&:

return (
    
      {user && (
        
          Bem-vindo, {user.name}
          Email: {user.email}
        
      );
    
  );

Nessa segunda forma, se o user não estivesse setado, nada seria exibido. É importante não utilizar números no lado esquerdo do operador &&, apenas comparações ou valores que podem ser convertidos em booleanos (por exemplo, se existe um user).

Listas

Para exibir os elementos de um array, deve-se usar as funções Map ou Filter do JS dessa forma:

const itemArray = ["item1", "item2", "item3"];

export const DisplayItems = () => {
    return(
      itemArray.map((item) => ({item})
  );
}

E agora?

Depois de uma longa jornada, minha demanda está em finalmente em produção! Encarar esse desafio me tornou uma desenvolvedora melhor, não só por aprender sobre mais uma tecnologia mas porque aprendi a pensar o desenvolvimento em si de uma forma diferente.
Se você, back-ender, precisa encarar uma demanda de front, saiba: this too shall pass. E não, não é o fim do mundo. Tente entender o padrão utilizado pela sua empresa, pesquise boas práticas, leia o código dos colegas e lembre-se: o debug é uma m**** mas pelo menos o feedback é imediato!