我认为,完全有理由等待因回调而得到的回应和更新。 这样做并不影响对非同步方法的注意。 它仍然完全松动,因为你没有阻止整页内容,也没有完全重新加载。

应用程序中很多次, 特别是在带宽可能受到限制的移动应用程序中, 我将会看到一个显示字段正在提交的旋转器。 这无法支撑应用程序的其他部分 。 我使用移动视图时, 即使是堆叠流也会这样做 。 重新点击回调, 以便保持同步, 并且仍然与数据库返回值同步 。

AJAX 呼叫速度相当快, 当然除了网络问题之外。 个人而言, 我不认为等待数据库回复会失去 AJAX 的好处 。 也就是说, 除非您计划由于服务器端处理等原因 速度缓慢, 否则您不会失去 AJAX 的好处...

如果您现在将文本字段设置为不可编辑状态, 用户可能会认为他的更改已被接受, 当服务器返回错误, 并且将值恢复到原来的状态时将会被混淆。 在服务器返回之前, 我会离开可以编辑的字段 。

如果你在使用jQuery,那很简单, 但是如果你在使用你的家庭brew ajax调用脚本, 你必须添加一些机制来检查一切是否顺利。

$.ajax({
 url:  /ajax/doSomething.php ,
 type:  POST ,
 dataType:  json ,
 data: {
   q : $("#editableText").val()
 },
 success: function(json) {
  $("#editableText").html(json.value);
 },
 error: {
  alert( something went wrong! );
 }
})

所以当你做一些事情.php 返回真实的或假的, 我们的ajax调用会根据它做一些事情。

是的 ajax 呼叫速度相当快, 但在更改页面上显示的数据之前, 我猜你必须确定一切是否顺利, 否则用户可能会在不知道他们是否做过编辑后离开页面 。

您提到的情况是优化 UI 更新。 您在此假设( 默认) 更新将在服务器上进行, 没有任何错误 。

这种办法的缺点是出现以下情况:

1. User clicks on non-editable text
2. Text becomes editable
3. User types in new text
4. User clicks send
5. The UI changes to the new text and makes it uneditable
6. User closes the browser window (or navigates away from the page) before the reply ever comes back (assuming that the change was performed)
7. Next time the user logs in (or comes back to the page) they are confused as to why the change did not apply!

然而,您还要使用ajax 的非同步性质,并确保用户在进行此更改时仍然可以与您的应用程序(或页面的其余部分)互动。

我们这样做的方式(在我的工作地点)通常是(用长长的投票或http推)

1. The user interacts with non-editable text
2. The text becomes editable
3. User types in new text
4. User clicks send
5. Instead of updating the text optimistically we show some kind of spinner (only on the text) that indicates to the user that we are waiting for some kind of response from the server. Note that since we are only disabling just the part of the page that shows this text the user does not have to wait for the ajax call to return in order to interact with the rest of the page. (In fact we have many cases that support updating multiple parts of the page in parallel). Think of gmail where you might be chatting with someone in the browser window and at the same time you get an email. The chat can go on and the email counter is also incremented. Both of them are on the same page but do not depend on each other (or wait for each other in any way)
6. When the update is complete we take away the spinner (which is usually shown using css - toggle class) and replace the element s value with the new text.

最后, 如果您正在做类似这样的事情, 请确保您的服务器也支持在文本字段中添加一个待处理类( 这将导致一个旋键出现) 。 这样做的原因如下 :

1. User updates text and submits
2. User immediately navigates to a different page
3. User then comes back to the original page again (and let us assume that the update is not yet complete)
4. Since your server knows that the field is being updated and can add a pending css class to the label / display field the page comes up loaded with a spinner.(On the other hand if there is no pending request there will be no spinner shown)
5. Finally when the long poller message comes back from the server the spinner is taken off and the current value is displayed