Biblioteca de leitura
Dê telas diferentes ao resultado vazio e à falha de transporte
Separe a busca vazia bem-sucedida dos erros HTTP e respostas perdidas, preservando a pergunta e tornando as novas tentativas deliberadas.
Defina classes de resposta
Uma área vazia não explica o que aconteceu. No caderno proposto, diferencie requisição em andamento, sucesso com registros, sucesso com data vazio, erro HTTP e tentativa sem resposta utilizável. São observações distintas. Um vazio bem-sucedido não prova ausência de discussões relevantes no arquivo; uma resposta perdida não revela se o servidor terminou. Não esconda essas interpretações no atalho visual sem resultados.
Use o estado HTTP junto da estrutura validada. Uma resposta 200 com data: [] é recuperação vazia bem-sucedida. HTTP 400, 401, 402, 429 e 502 são erros, não variantes de sucesso vazio. Uma exceção de rede pode não oferecer estado HTTP. Não deduza apenas do erro se todas as etapas do backend ocorreram. Guarde parâmetros e identificador de requisição do aplicativo para associar respostas tardias à busca correta.
Escreva ações para o estado vazio
Use texto contido, como Nenhum registro foi retornado para esta requisição. Mostre q=quantization e subreddit=LocalLLaMA com restrições ativas de data ou pontuação. Permita editar uma condição e enviar de novo intencionalmente. Não substitua o vazio por discussões populares inventadas nem amplie automaticamente mantendo o rótulo antigo. Remover um filtro faz o novo resultado pertencer a outra requisição, cuja sequência deve iniciar em page=1.
Explique uma restrição sem fingir diagnosticar a ausência. Em quantization memory, os termos precisam corresponder dentro de um title ou text; distribuí-los entre ambos não basta. É uma consideração, não a causa comprovada do vazio. Preserve a diferença de cobrança: recuperação vazia bem-sucedida custa um crédito. Uma página vazia avançada pode ter total desconhecido. Não transforme isso em zero correspondências em todo o arquivo ou motivo para pedir páginas indefinidamente.
Escreva ações para as falhas
Direcione a falha a quem pode agir. HTTP 400 exige examinar a entrada, como parâmetro não suportado ou data diferente de YYYY-MM-DD. HTTP 401 diz respeito à chave do serviço; 402, aos créditos disponíveis na conta. Nenhum estabelece que o login pessoal do leitor expirou. O operador pode precisar corrigir a credencial do backend ou revisar o saldo. Não peça ao leitor colar a chave do serviço no buscador público.
Para 429, respeite Retry-After e reduza envios repetidos. Para 502, conserve a consulta e ofereça nova tentativa consciente quando apropriado; a devolução do crédito reservado pode aguardar conciliação. Sem resposta, reconheça que o resultado, inclusive a cobrança, é desconhecido. Rejeições anteriores à reserva não são cobradas, mas desconexão não prova essa rejeição. /v1/status é gratuito, com declaração estática e resposta HTTP; não resolve a requisição perdida nem verifica a saúde da busca.
Teste a continuidade da navegação
Continuidade também exige preservar a entrada. Planeje casos locais para vazio válido, erro HTTP e exceção de rede anterior à resposta. Use material explicitamente sintético: os casos testariam a interface, não a disponibilidade do arquivo. Verifique mensagens diferentes e acesso à consulta enviada. Acrescente o caso de editar o formulário enquanto a requisição aguarda: o resultado antigo não pode parecer resposta à expressão nova.
Se a próxima página falhar, mantenha os registros carregados e diferencie seu estado concluído da continuação fracassada. Deixe tentar aquela página ou voltar ao formulário sem enviar outra requisição escondida. Ignorar resposta tardia não garante cancelar o trabalho do servidor. Registre transições realmente testadas e aquelas ainda propostas. A meta é explicar o conhecido e oferecer um passo útil, não tranquilizar com mensagens sem sustentação na resposta.
