O que você procura quando revisa o pull request de React de alguém?

Correção do fluxo de dados primeiro: onde o estado mora, se os efeitos são necessários e têm dependências honestas, e se as keys são estáveis. Depois as bordas visíveis para o usuário, que são os estados de carregando, vazio e erro, mais acesso por teclado e leitor de tela. Depois performance, só onde ela é mensurável. Estilo e nomenclatura vêm por último, e qualquer coisa que um linter ou formatter possa decidir não deveria nem ser um comentário de revisão.

Eu leio a descrição e os testes primeiro, depois o diff, porque eu quero saber o que a mudança pretende fazer antes de julgar como ela faz. Minha primeira passada é fluxo de dados. Onde mora esse estado, ele poderia morar mais baixo, aquele efeito é realmente necessário ou é estado derivado, as dependências são honestas ou alguém silenciou a regra do lint na surdina, e as keys da lista são estáveis. A segunda passada são as bordas, que é onde a maioria dos bugs vai para produção: o que isso renderiza enquanto carrega, quando a lista está vazia, e quando a requisição falha, e eu consigo operar isso com o teclado. A terceira é performance, mas só se eu conseguir apontar um custo real, não um palpite. Eu tento marcar os comentários como bloqueantes ou apenas uma ideia, porque implicâncias sem rótulo travam pull requests por dias. E eu nunca comento sobre formatação ou ordem de imports; se importa, o lugar é o linter, não a minha opinião.