Todos nós já passamos por isso. Você abre um componente React que escreveu há alguns meses e parece que está olhando um código escrito por alguém que estava com pressa - porque provavelmente você estava. Os prazos estavam se aproximando e os recursos precisavam ser enviados. Avançando até hoje, é hora de refatorar esse componente confuso.

Então, aqui está como eu resolvi isso.

O terror inicial

A primeira coisa que notei foi que o componente havia crescido muito. Ele estava tentando fazer tudo, como lidar com o estado, fazer chamadas de API, gerenciar lógica de interface de usuário complexa e até mesmo aplicar estilos diretamente. Era um único arquivo com mais de 540 linhas, e lê-lo parecia estar em uma selva sem mapa.

O primeiro passo foi aceitar a realidade: esse código não era mais sustentável. Se eu, a pessoa que o escreveu, mal conseguisse acompanhar o que estava acontecendo, outra pessoa não teria a menor chance. Então, decidi decompô-lo.

Dividindo

Comecei identificando as diferentes responsabilidades do componente. Havia três áreas claras:

1. Gerenciamento de estado: o tratamento do estado do componente estava interligado à lógica da UI.

2. Chamadas de API: busca de dados e tratamento de estados de carregamento.

3. IU de renderização: exibindo os dados em uma estrutura de IU um tanto complexa.
   Cada uma dessas responsabilidades precisava ser separada.

Extraindo ganchos para estado e lógica de API

A primeira coisa que fiz foi extrair o gerenciamento de estado e a lógica da API em ganchos personalizados. Isso não apenas limpou o componente, mas também tornou mais fácil testar e reutilizar a lógica em outro lugar.

Mencionando algum código aqui (não o original):

function useDataFetching(apiEndpoint) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    async function fetchData() {
      try {
        let response = await fetch(apiEndpoint);
        let result = await response.json();
        setData(result);
      } catch (err) {
        setError(err);
      } finally {
        setLoading(false);
      }
    }

    fetchData();
  }, [apiEndpoint]);

  return { data, loading, error };
}

Com useDataFetching, retirei a lógica de chamada da API e lidei com os estados de carregamento e erro. Agora, o componente só precisa chamar esse gancho e obter os dados necessários, limpos e simples.

Simplificando a lógica da UI
Em seguida, examinei a lógica de renderização. Anteriormente, eu estava verificando carregamento, erros e dados, tudo dentro da função de renderização, o que tornava bastante difícil acompanhar. Separei essa lógica em funções pequenas e independentes, mais ou menos assim (claro que não a original;)

function renderLoading() {
  return 
Loading...
;
}

function renderError(error) {
  return 
Error: {error.message}
;
}

function renderData(data) {
  return 
{/* Complex UI logic here */}
;
}
//After that, component is ni much pretty shape

function MyComponent() {
  const { data, loading, error } = useDataFetching('/api/data-endpoint');

  if (loading) return renderLoading();
  if (error) return renderError(error);
  if (data) return renderData(data);

  return null;
}

Conversa Final

Depois de quebrar o componente, o arquivo passou de mais de 540 linhas para cerca de 124, com uma lógica muito mais fácil de seguir. O componente agora faz uma coisa: renderizar a UI. Todo o resto foi transferido para ganchos personalizados e funções utilitárias.

Essa experiência reforçou algumas lições importantes para mim:

• Não tema a refatoração: é fácil deixar o código confuso como está, especialmente quando funciona. Mas reservar um tempo para limpá-lo torna a sua vida - e a vida do seu futuro - muito mais fácil.

• Separação de preocupações: manter diferentes preocupações em locais diferentes (estado, API, UI) tornou o código mais modular, reutilizável e testável.

• Keep It Simple: simplificar a função de renderização transferindo a lógica para funções menores tornou o componente muito mais legível.

Então, se você tem um componente confuso como você, não hesite em refatorar. Não se trata apenas de código limpo – trata-se de tornar sua vida mais fácil como desenvolvedor. E quem não gostaria disso?