You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You have a couple of similar issues to some teams last week.
Button click-handlers
You should always attach click-handlers to buttons. They are the main semantic interactive element in HTML, they are focusable and have keyboard-support built-in. Adding a click-handler to a parent element and checking the tagName is not necessary, and probably a worse experience for some users.
You also don't ever send a response, which means the fetch request in the browser will never end. Since you refresh the page straight away this kind of doesn't matter, but it means you have an active request hanging around on your server until it times out. You should always set a status code and call response.end(), even if you're returning no body.
fetch callback
You aren't actually passing a function to the fetch's .then. The parentheses after the window.location.reload() mean that will execute immediately (i.e. as soon as the user clicks the button). This means your delete request is racing against your page reload, so it's possible the homepage willl load before the delete completes and you'll see an incorrect page.
You want to pass a function to: .then(() => window.location.reload()).
Error-handling
Your deleteHandler could do with some error-handling to avoid unhandled promise rejections if something goes wrong. Ideally you need both a .catch on the DB query and a request.on("error").
My suggestion
There's a simpler way that doesn't require any client-side JS at all: send a GET /delete-post?id=1 request using a standard anchor tag. You can server render the anchor tags with the POST ID inside your makeArticle template, using obj.id. So instead of a button you'd have an <a href="/delete-post?id=${obj.id}">. Then you can update your router to use that URL for the deleteHandler
The text was updated successfully, but these errors were encountered:
You have a couple of similar issues to some teams last week.
Button click-handlers
You should always attach click-handlers to buttons. They are the main semantic interactive element in HTML, they are focusable and have keyboard-support built-in. Adding a click-handler to a parent element and checking the tagName is not necessary, and probably a worse experience for some users.
You also don't ever send a response, which means the
fetch
request in the browser will never end. Since you refresh the page straight away this kind of doesn't matter, but it means you have an active request hanging around on your server until it times out. You should always set a status code and callresponse.end()
, even if you're returning no body.fetch
callbackYou aren't actually passing a function to the fetch's
.then
. The parentheses after thewindow.location.reload()
mean that will execute immediately (i.e. as soon as the user clicks the button). This means your delete request is racing against your page reload, so it's possible the homepage willl load before the delete completes and you'll see an incorrect page.You want to pass a function to:
.then(() => window.location.reload())
.Error-handling
Your
deleteHandler
could do with some error-handling to avoid unhandled promise rejections if something goes wrong. Ideally you need both a.catch
on the DB query and arequest.on("error")
.My suggestion
There's a simpler way that doesn't require any client-side JS at all: send a
GET /delete-post?id=1
request using a standard anchor tag. You can server render the anchor tags with the POST ID inside yourmakeArticle
template, usingobj.id
. So instead of a button you'd have an<a href="/delete-post?id=${obj.id}">
. Then you can update your router to use that URL for the deleteHandlerThe text was updated successfully, but these errors were encountered: