Tôi hiểu rằng lý do đằng sau nó là nó nhanh hơn một chút và có tùy chọn để làm được nhiều việc hơn với dữ liệu thô thay vì truy xuất html
Nhưng tôi chưa thể tìm thấy các ví dụ hay giải thích rõ ràng cách thực sự chuyển đổi dữ liệu JSON thành đầu ra HTML mong muốn
Ví dụ, tôi có một nút thích
3
Biểu tượng này hiển thị là biểu tượng thích và số lượt thích mà mục đó đã có [trong ví dụ này là 3]
Những gì tôi muốn đạt được là nhấp vào nút đó, tải url /reactions/save bằng ajax, lưu lượt thích mới và sau đó thay đổi nút để cho biết rằng mục này đã được thích và thay đổi .
Về cơ bản giống như facebook hay bất kỳ trang web nào khác đều có nút thích, giống như trang web này có nút thích.
Những gì tôi thường làm là đính kèm nút đó vào một chức năng jquery sẽ tải url đó khi nhấp vào nó, url sẽ trả về nút mới đã được định dạng [nó sẽ trả về HTML] và tôi sẽ sử dụng jquery để chỉ thay thế hai nút
Nhưng khi tôi đọc và được thông báo liên tục, tốt hơn là truy xuất JSON và định dạng dữ liệu đó vào nút
Tôi chỉ không hiểu làm thế nào và nếu chỉ lấy HTML từ phản hồi và xuất ra nó thì sẽ không đơn giản hơn nhiều thay vì lấy dữ liệu JSON, định dạng và sau đó xuất ra nó
Lúc đầu, việc trả lại đánh dấu từ chương trình phụ trợ có vẻ dễ dàng hơn, nhưng về lâu dài chắc chắn sẽ gặp nhiều rắc rối hơn vì bạn phải duy trì đánh dấu [hoặc các đoạn đánh dấu] ở nhiều nơi; . Và không có cách nào bạn có thể truy vấn bất kỳ dữ liệu có ý nghĩa nào từ một ứng dụng khác
Một vấn đề khác là bằng cách hủy các phần tử ban đầu, bạn sẽ mất tất cả các trình xử lý sự kiện đã thêm trước đó - hoặc tệ hơn, bạn vẫn có các tham chiếu đến các phần tử đó khiến chúng không bị thu gom rác, do đó tạo ra rò rỉ bộ nhớ. Bằng cách sử dụng lại các phần tử giống nhau, bạn không phải lo lắng về việc hủy bỏ các tham chiếu hoặc áp dụng lại các trình xử lý sự kiện [điều này rõ ràng cũng tiết kiệm hơn về mặt hiệu suất]
Tất cả đều rất không rõ ràng đối với tôi và có vẻ như điều đó có nghĩa là tạo ra nhiều hàm javascript cho từng loại phần tử tôi muốn cập nhật
Tôi không chắc ý của bạn là gì… tất nhiên nó phụ thuộc vào độ phức tạp, nhưng trong đoạn mã trên của tôi, đó chỉ là 1 hàm có 2 dòng, nếu không thì sẽ là một hàm có 1 dòng gán đánh dấu. Được rồi ví dụ xấu, đây thực sự là gấp đôi. :-D Dù sao thì với cách tiếp cận của bạn OTOH, bạn phải mở rộng phần phụ trợ cho từng loại phần tử mới [và có thể làm tăng API], vì vậy tôi không thực sự thấy lợi thế trong đó
Nếu mọi thứ không thành công, bạn vẫn có thể tạo đánh dấu từ dữ liệu bằng cách sử dụng JS, giống như bạn làm trong phần phụ trợ;
cách rõ ràng nhất có lẽ là sử dụng một mẫu ngay từ HTML ban đầu . g.
You liked this!
const buttonTemplate = document.getElementById['button-template']
const likeForm = document.getElementById['like-form']
// Then at some point...
likeForm.innerHTML = buttonTemplate.innerHTML
// Or:
const button = likeForm.querySelector['button']
button.replaceWith[buttonTemplate.content]
Bằng cách này, bạn vẫn có tất cả đánh dấu ở một nơi, nhưng tất nhiên, một lần nữa bạn phải cẩn thận với rò rỉ bộ nhớ; . g. nếu button ở trên vẫn được tham chiếu ở nơi khác
Tôi không chắc ý của bạn là gì…
Ý tôi là theo những gì tôi hiểu, cách tốt nhất để làm việc với ajax là nhận phản hồi JSON, sau đó sử dụng một hàm javascript khác để triển khai hoặc đưa phản hồi JSON đó vào html.
Điều tôi hiểu từ điều này là nếu tôi có một trang web có nhiều yêu cầu ajax khác nhau, thì điều đó có nghĩa là tôi cần có một chức năng dành riêng cho từng loại phần tử mà tôi muốn .
- một chức năng js cho một danh sách bài viết
- một chức năng js cho một nút thích
- một chức năng js cho một menu
- vân vân …
Đó là những gì tôi hiểu từ mọi thứ, rằng khi bạn nhận được phản hồi JSON từ ajax, bạn cần “Chuyển đổi” nó thành biểu diễn html chính xác mà bạn muốn. Đối với tôi, điều đó có nghĩa là bạn cần một chức năng cho mọi loại phần tử html mà bạn muốn tải lại bằng ajax [phần tử bài đăng, phần tử danh sách bài đăng, nút thích, v.v. , một chức năng cho mỗi loại đó]
Có lẽ tôi không hiểu, có vẻ như chúng ta đang nói hai ngôn ngữ khác nhau
Dù sao với cách tiếp cận của bạn OTOH, bạn phải mở rộng phần phụ trợ cho từng loại phần tử mới [và có thể làm tăng API], vì vậy tôi không thực sự thấy lợi thế trong đó
Cách tôi cấu trúc các tệp của mình là nếu tôi có một tệp có định dạng html mà tôi muốn tải lại bằng ajax, tôi sẽ lưu tệp đó vào một tệp và thư mục riêng biệt, vì vậy, chẳng hạn, nó sẽ là. renders/like_button.php.
Tệp này sẽ được đưa vào bất cứ nơi nào tôi muốn hiển thị nút thích và nếu tôi muốn sử dụng nó trong ajax, tôi chỉ cần lấy tệp có yêu cầu ajax và thay thế nút hiện có bằng tệp đó.
Vì vậy, tôi không có thêm bất kỳ tệp html nào cho ajax, tôi sử dụng những tệp mà tôi đã sử dụng với tải thông thường.
Bạn có thể cung cấp gợi ý cho hướng dẫn chính thức/chi tiết hơn về kỹ thuật này nói chung không?
Vấn đề là, tôi không tin rằng chỉ truyền JSON và sau đó sử dụng JS để cập nhật DOM là thực sự tốt hơn. Tôi nghĩ mọi người có thể đang đánh giá quá cao lợi ích của việc tách biệt dữ liệu khỏi phần trình bày của nó. Vâng, rõ ràng là có những lợi thế. Bạn đang đẩy bản trình bày đến nơi dữ liệu được trình bày - trên máy khách. Điều này giúp bạn tiến gần hơn đến mối quan hệ MVC thực vì sau đó bạn có thể chỉ cần cập nhật “mô hình” ở dạng cập nhật JSON trên máy khách và “chế độ xem” cập nhật phản ứng với những thay đổi đó. Nhưng thật không may, chuỗi công cụ HTML, JavaScript, CSS hiện tại không cung cấp chức năng cần thiết để triển khai hiệu quả điều đó. Ngay cả một hệ thống mẫu phía máy khách có thể liên kết các trường trong chế độ xem với dữ liệu một cách minh bạch sao cho nó phản ứng với những thay đổi trong dữ liệu sẽ không đủ vì có những trường hợp dom thay đổi hoàn toàn khi thêm các phần tử mới vào danh sách và cây phần tử. Tải trước các mẫu nội dung có thể không khả thi hoặc thực tế. Nội dung có thể dễ dàng rất đa dạng hoặc thậm chí hoàn toàn độc đáo
Ngoài ra, tôi không hiểu tại sao hiệu suất nhất thiết phải tốt hơn bởi vì bạn đang làm rất nhiều việc ngay từ đầu. Bạn phải tạo mọi đoạn HTML có thể có sẽ được trang sử dụng từ đầu [và những đoạn đó thậm chí có thể không được sử dụng]. Ban đầu, khách hàng sẽ cần phân tích cú pháp nhiều JS hơn. Và mọi lợi ích về hiệu suất sẽ được giới hạn ở máy chủ. Máy khách rõ ràng sẽ không hiệu quả hơn vì hiện tại nó đang xử lý khá nhiều cập nhật động cho DOM mà trình duyệt phải diễn giải lại để thay đổi chế độ xem
Ý tưởng tách dữ liệu khỏi biểu diễn của nó là rất hay nhưng trên thực tế, mỗi thao tác có thể chỉ cần một phần nhỏ dữ liệu ở dạng JSON. Có nghĩa là nếu bạn có một dịch vụ JSON chung và khách hàng chỉ muốn biết ai đó có bao nhiêu “lượt thích”, thì loại mã cơ sở dữ liệu nào đang được gọi để có được điều đó?
Bạn đề cập đến các phụ thuộc nhưng hãy xem xét các phụ thuộc của phương thức cập nhật JSON phía máy khách này. Nếu bạn thực hiện thay đổi, bạn có thể phải cập nhật “mẫu” HTML được tải sẵn, dữ liệu JSON, sau đó là JS bổ sung được sử dụng để thao tác DOM và thủ thuật 'nội dung' CSS bổ sung được sử dụng để cập nhật "mẫu". Ngoài ra, nếu bạn chỉ phát ra một đoạn HTML và đính kèm nó vào DOM, thì bạn chỉ đang thay đổi mẫu phía máy chủ [ví dụ như một mẫu thực như PHP để nó dễ sử dụng hơn RẤT NHIỀU] và một số JS tương đối đơn giản và
Nó cũng khó hơn để làm mọi thứ trên máy khách. Máy chủ có thể có các thư viện phức tạp không có trên máy khách. Tuy nhiên, phương pháp này đẩy rất nhiều công việc cho khách hàng một cách hiệu quả. Vì vậy, mọi quyết định đưa vào kết xuất đều bị giới hạn ở những gì có thể được thực hiện trong JS
Vì vậy, những người khác đang ủng hộ phương pháp này? . Tôi sẽ phải hiểu điều này tốt hơn rất nhiều để thực hiện bước nhảy vọt
Tệp này sẽ được đưa vào bất cứ nơi nào tôi muốn hiển thị nút thích và nếu tôi muốn sử dụng nó trong ajax, tôi chỉ cần lấy tệp có yêu cầu ajax và thay thế nút hiện có bằng tệp đó
À được rồi đủ công bằng. Vấn đề chính vẫn là phụ trợ phải cung cấp điểm cuối cho mọi yếu tố có thể, thay vì chỉ cung cấp dữ liệu và để giao diện người dùng quyết định phải làm gì với dữ liệu đó
Tôi nghĩ mọi người có thể đang đánh giá quá cao lợi ích của việc tách biệt dữ liệu khỏi phần trình bày của nó
Xin chào @ioplex, kết hợp tốt dữ liệu với bản trình bày không mở rộng tốt. Bất cứ khi nào giao diện người dùng cần một số điều chỉnh nhỏ, ai đó phải đến nhóm phụ trợ và nói với họ rằng họ cần một lớp bổ sung hoặc điểm cuối bổ sung phục vụ đánh dấu hơi khác. Điều đó không chỉ làm chậm quá trình phát triển mà còn ngày càng khó bảo trì hơn
Ngay cả một hệ thống mẫu phía máy khách có thể liên kết các trường trong chế độ xem với dữ liệu một cách minh bạch sao cho nó phản ứng với những thay đổi trong dữ liệu sẽ không đủ vì có những trường hợp dom thay đổi hoàn toàn khi thêm các phần tử mới vào danh sách và cây phần tử. Tải trước các mẫu nội dung có thể không khả thi hoặc thực tế
Bạn vẫn có thể xây dựng đánh dấu từ đầu, nếu bằng cách đặt innerHTML – Tôi không thấy điều này khác với việc lắp ráp đánh dấu ở phía máy chủ như thế nào, chỉ có điều là JS cũng có ít phương tiện thô sơ hơn để cập nhật DOM [nếu thực sự có thể áp dụng]. Và nói về các công cụ mẫu, một số thậm chí còn có các triển khai cho cả ngôn ngữ phía máy chủ JS và [khác]… e. g. pug OTTOMH
Ngoài ra, tôi không hiểu tại sao hiệu suất nhất thiết phải tốt hơn bởi vì bạn đang làm rất nhiều việc ngay từ đầu. Bạn phải tạo mọi đoạn HTML có thể có sẽ được trang sử dụng từ đầu [và những đoạn đó thậm chí có thể không được sử dụng]
Không, bạn không cần phải làm vậy, bạn cũng có thể lười tải chúng khi cần. Ví dụ, với các gói như webpack, bạn thậm chí có thể nhập trực tiếp HTML vào JS
import['./my-template.html'].then[html => {
myElement.innerHTML = html
}]
Phải thừa nhận rằng đây là một chủ đề khá nâng cao, nhưng bạn đã đề cập đến chuỗi công cụ giao diện người dùng. :-P Dù sao đi nữa, theo cách này, bạn chỉ tải mẫu một lần khi cần và sử dụng lại mẫu đó khi yêu cầu thêm dữ liệu [chỉ đơn giản là nó được trình duyệt lưu vào bộ đệm];
đó là một mẫu thực như PHP chẳng hạn, vì vậy nó dễ sử dụng hơn RẤT NHIỀU
PHP chỉ là một ngôn ngữ giống như JS, nó không phải là một khuôn mẫu. Cả hai đều có cách để nội suy các chuỗi và không thiếu các công cụ mẫu cho cả hai