Solucionado (ver solução)
Solucionado
(ver solução)
1
resposta

uso do remove-livro.js no lado do navegador

Olá estou com uma dúvida. A implantação do recurso de remoção colocamos a responsabilidade de remover o livro a um arquivo estativo remove-livro.js que faz uma procura pelo elemento com um id específico e então acessa o recurso de deleção pelo fetch API. A questão que fiquei me perguntando é a seguinte: não deveria este recurso da aplicação ser realizado no servidor. Fiz o teste desabilitando o javascript do navegador e não funcionou. Outra coisa: um usuário mal intencionado e com conhecimentos de javascript não poderia passar um excript de alterando dados não desejados.

Haveria um solução para deletar apenas com recurso do lado do servidor.

app.delete('/livros/:id', (req, resp)=>{
        const id = req.params.id;
        const livroDAO = new LivroDAO(db);
        livroDAO.remove(id)
        .then(resp.redirect('/livros'))
        .catch(erro => console.log(erro));
    });

tentei alterar fazer isso com o código acima, porém não deu resultado.

1 resposta
solução!

Bom dia, Wesley! Como vai?

O livro só é efetivamente removido do lado do servidor! O que o remove-livro.js faz é apenas apagar a linha da tabela e pedir pro servidor remover o dado do BD!

Além disso, a gente poderia fazer um link que faz a requisição para o servidor da forma comum! Só que fazendo isso, a gente cairia num problema grave de performance, pois seríamos obrigados a recarregar toda a lista de livros quando na realidade o que queremos é remover apenas 1 livro e manter o restante carregado na tela! Imagine a dor de cabeça que seria recarregar uma listagem de 999 livros apenas pq removemos 1... Seria péssimo!

É justamente para resolver situações como essas que a boa prática é lançar mão do AJAX como feito por mim através do arquivo remove-livro.js, onde fazemos uma requisição assíncrona com o JavaScript pedindo para que o servidor execute uma ação para a gente! É claro que, assim como vc percebeu, o usuário pode desabilitar o JS e quebrar a aplicação! E pra resolvermos isso a gente poderia recorrer ao recarregamento geral dos livros, mas isso seria apenas a opção secundária que normalmente é chamada de fallback!

Por último, independentemente da abordagem ( usando AJAX como eu fiz durante o curso ou usando a abordagem que vc sugeriu ), um usuário mal intencionado poderia tentar o que quisesse! E aí o desenvolvedor do back-end precisa pensar nessas questões e usar estratégias de prevenção, como autenticação e autorização que são assuntos tratados na segunda parte do curso!

Pegou a ideia? Qualquer coisa é só falar!

Grande abraço e bons estudos, meu aluno!