Ask HN: Ajax for HN 'reply' links?
Rather than being directed to a new page to enter your reply to a HN comment, wouldn't it be nice if the 'reply' link allowed you to post the response by Ajax with no page refresh?
3 comments
Having implemented this once or twice, it's actually pretty difficult. You have to first make sure the POST goes through and validates. This means you need an error display system in place to catch errors (What if the comment you replied to is now deleted or edited? And so on--so you should keep a tally of the state around the comment) and a way for the backend to report errors to the AJAX.
Now, if it goes through, you need to return a success code. On success, the AJAX will have to duplicate a non-AJAX request. That means finding the right place to insert the comment with the right parent ancestor. You could pass that back with the success code, which means you'll have to run the sorting routine first, which means it has to be re-factored out of whatever controller it's currently residing in. Or you could just remove all the comments from DOM and reload them from the back-end. But, by then, you're nearing the point where it's just as slow as doing a redirect.
Usually, (reddit-style) the comment just gets placed with the right ancestor and nothing is re-sorted. A little inconsistency, which irks me but it's acceptable.
And this all has to be done without modifying the HTML unduly so that people without JavaScript can still submit as usual: This means you now have two code paths to test where you previously had one, which I consider the biggest downside. What if you add a new feature or change an existing one? Et cetera.
It's all very tricky to do, and I've usually only seen it done on projects where everything else was already AJAXed and comments would've stuck out had they not also gone under the same powder and makeup.
OK, so this comment turned out to be more negative than I intended in the spirit of spinning out the "what-if".
Now, if it goes through, you need to return a success code. On success, the AJAX will have to duplicate a non-AJAX request. That means finding the right place to insert the comment with the right parent ancestor. You could pass that back with the success code, which means you'll have to run the sorting routine first, which means it has to be re-factored out of whatever controller it's currently residing in. Or you could just remove all the comments from DOM and reload them from the back-end. But, by then, you're nearing the point where it's just as slow as doing a redirect.
Usually, (reddit-style) the comment just gets placed with the right ancestor and nothing is re-sorted. A little inconsistency, which irks me but it's acceptable.
And this all has to be done without modifying the HTML unduly so that people without JavaScript can still submit as usual: This means you now have two code paths to test where you previously had one, which I consider the biggest downside. What if you add a new feature or change an existing one? Et cetera.
It's all very tricky to do, and I've usually only seen it done on projects where everything else was already AJAXed and comments would've stuck out had they not also gone under the same powder and makeup.
OK, so this comment turned out to be more negative than I intended in the spirit of spinning out the "what-if".
It doesn't matter if the comment you're replying to is deleted or edited, your comment goes on it's position in the comment "tree" even if the branch that your comment is on no longer has any other leaves your comment still goes there.
Plenty of other places have AJAX threaded comments and seem to manage.
Plenty of other places have AJAX threaded comments and seem to manage.
Negative, but great comment - very much reminiscent of Steve Yegge's Shit's Easy Syndrome, one of my favorite pieces of tech blogging.