Khi thực hiện chỉnh sửa AJAX cho cơ sở dữ liệu, tôi có nên cập nhật giao diện ngay lập tức với dữ liệu mới

Question

Tôi đang sử dụng chỉnh sửa nội tuyến để cập nhật văn bản trong cơ sở dữ liệu bằng AJAX hay không. Đây là về cơ bản quá trình này, công cụ khá thông thường:

• văn bản là không thể chỉnh sửa
• tôi nhấp vào văn bản, nó trở nên có thể chỉnh sửa
• tôi gõ văn bản mới
• sau đó bấm vào để gửi văn bản cập nhật để cơ sở dữ liệu
• sau đó trả lại văn bản sang định dạng không thể chỉnh sửa

câu hỏi của tôi là khi tôi nên cập nhật giao diện với các dữ liệu mới? Tôi có nên cập nhật nó ngay trước cuộc gọi ajax hay tôi nên chờ phản hồi cập nhật để trả về từ cơ sở dữ liệu?

mối quan tâm của tôi:

• Nếu tôi không cập nhật giao diện ngay lập tức và chờ đợi để có được những phản hồi từ các cơ sở dữ liệu, sau đó tôi đã đánh mất lợi ích không đồng bộ mà đi kèm với ajax.
• Nhưng nếu tôi cập nhật nó ngay lập tức, sau đó nếu phản hồi cơ sở dữ liệu có lỗi, tôi bằng cách nào đó phải theo dõi sự thay đổi mà tôi đã thực hiện, và ngược lại, đó là nhiều công việc hơn.

Vì vậy, việc này thường được thực hiện như thế nào?

Answer 1

Tôi nghĩ hoàn toàn hợp lý để chờ phản hồi và cập nhật do kết quả của cuộc gọi lại. Làm như vậy không làm giảm cách tiếp cận không đồng bộ. Nó vẫn hoàn toàn không đồng bộ vì bạn không chặn toàn bộ trang hoặc tải lại hoàn toàn.

Rất nhiều lần trong ứng dụng, đặc biệt là trong các ứng dụng dành cho thiết bị di động nơi băng thông có thể bị giới hạn, tôi sẽ thấy trình quay số cho biết trường đang gửi. Điều này không giữ bất kỳ phần nào khác của ứng dụng. Ngay cả stackoverflow hiện này khi tôi sử dụng xem di động. Dựa vào các cuộc gọi lại để giữ nguyên async và vẫn được đồng bộ hóa với các giá trị trả về của cơ sở dữ liệu.

Answer 2

Cuộc gọi AJAX khá nhanh, ngoại trừ các sự cố mạng. Cá nhân, tôi không nghĩ rằng bạn sẽ mất lợi ích của AJAX bằng cách chờ phản hồi từ cơ sở dữ liệu. Tức là, trừ khi bạn lên kế hoạch chậm vì xử lý phía máy chủ, v.v ...

Bây giờ nếu bạn đặt trường văn bản thành trạng thái không thể chỉnh sửa, người dùng có thể nghĩ rằng thay đổi của mình đã được chấp nhận và sẽ bị nhầm lẫn khi máy chủ trả về lỗi và giá trị được hoàn nguyên về trạng thái ban đầu của nó. Tôi sẽ rời khỏi trường có thể chỉnh sửa cho đến khi máy chủ trả về.

Answer 3

Nếu bạn đang sử dụng jQuery nó khá đơn giản, nhưng nếu bạn đang sử dụng kịch bản lệnh gọi homebrew ajax, bạn sẽ phải thêm một số cơ chế để xem mọi thứ có tốt hay xấu.

$.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!'); 
} 
}) 

Vì vậy, khi doSomething.php của bạn trả về true hoặc false, các cuộc gọi ajax của chúng tôi sẽ thực hiện theo một điều gì đó.

Có các cuộc gọi ajax khá nhanh, nhưng trước khi thay đổi dữ liệu được hiển thị trên trang, tôi đoán bạn phải chắc chắn mọi thứ đã ổn, nếu không người dùng có thể rời khỏi trang mà không biết họ có chỉnh sửa hay không.

Answer 4

Trường hợp bạn đã đề cập là cập nhật giao diện người dùng Optimistic. Trong trường hợp này, bạn giả sử (ngụ ý) rằng bản cập nhật sẽ được thực hiện trên máy chủ mà không có bất kỳ lỗi nào.

Điều bất lợi cho cách tiếp cận này sẽ có một kịch bản sau đây

1. Người dùng nhấp vào văn bản không thể chỉnh sửa
2. chữ trở nên có thể chỉnh sửa
3. loại dùng trong văn bản mới
4. Người dùng nhấp chuột gửi
5. Giao diện người dùng thay đổi thành văn bản mới và làm cho nó không thể chỉnh sửa
6. Người dùng đóng cửa sổ trình duyệt (hoặc điều hướng khỏi trang) trước khi câu trả lời trở lại (giả sử rằng thay đổi đã được thực hiện)
7. Lần tiếp theo người dùng đăng nhập (hoặc quay lại trang) họ bị nhầm lẫn là tại sao thay đổi không được áp dụng!

Tuy nhiên bạn cũng muốn sử dụng tính chất không đồng bộ của ajax và đảm bảo rằng người dùng vẫn có thể tương tác với ứng dụng của bạn (hoặc phần còn lại của trang) khi thay đổi này đang được thực hiện.

Cách chúng tôi làm điều đó (tại công việc của tôi chỗ) thường sẽ là (sử dụng phiếu dài hoặc http push)

1. Người dùng tương tác với văn bản không thể chỉnh sửa
2. Các văn bản trở nên có thể chỉnh sửa
3. Các loại người dùng trong văn bản mới
4. Nhấp chuột của người dùng gửi
5. Thay vì cập nhật văn bản một cách lạc quan, chúng tôi hiển thị một loại spinner (chỉ trên văn bản) cho người dùng biết rằng chúng tôi đang chờ đợi một số loại sponse từ máy chủ. Lưu ý rằng vì chúng tôi chỉ vô hiệu hóa một phần của trang hiển thị văn bản này nên người dùng không phải chờ cuộc gọi ajax để trả lại để tương tác với phần còn lại của trang. (Trong thực tế, chúng tôi có nhiều trường hợp hỗ trợ cập nhật nhiều phần của trang song song). Hãy nghĩ về gmail nơi bạn có thể trò chuyện với ai đó trong cửa sổ trình duyệt và đồng thời bạn nhận được email. Trò chuyện có thể tiếp tục và bộ đếm email cũng được tăng lên. Cả hai đều nằm trên cùng một trang nhưng không phụ thuộc vào nhau (hoặc đợi nhau theo bất kỳ cách nào)
6. Khi cập nhật xong, chúng tôi lấy đi spinner (thường được hiển thị bằng cách sử dụng css - toggle class) và thay thế giá trị của phần tử bằng văn bản mới.

Cuối cùng, nếu bạn làm như thế này, hãy đảm bảo rằng máy chủ của bạn cũng hỗ trợ thêm lớp đang chờ xử lý vào trường văn bản (điều này sẽ làm cho trình quay xuất hiện). Này được thực hiện đối với các lý do sau

1. cập nhật tài khoản văn bản và nộp
2. tài khoản ngay lập tức điều hướng đến một trang khác
3. tài khoản sau đó trở lại trang ban đầu một lần nữa (và chúng ta hãy giả định rằng bản cập nhật không phải là chưa hoàn thành)
4. Vì máy chủ của bạn biết rằng trường này đang được cập nhật và có thể thêm lớp css đang chờ xử lý vào trường nhãn/hiển thị, trang này được tải bằng trình quay tròn.(Mặt khác nếu không có yêu cầu đang chờ sẽ có không spinner hiển thị)
5. Cuối cùng khi được thông báo poller dài trở lại từ máy chủ spinner được lấy ra và giá trị hiện tại được hiển thị