使用Node.js和Socket.io實時更新大型HTML內容

Question

我正在構建一個Web應用程序，該應用程序將根據一個客戶端所做的更改來更新每個客戶端網頁的HTML內容，為此，到目前為止，我正在使用Node.js的Socket.io。

我正在使用HTML5的contenteditable屬性，以允許客戶端手動編輯div元素的內容，該元素也需要為其他客戶端更新。

我面臨的問題是我不了解通過websocket發送哪些數據來通知服務器以及其他客戶端所做的更改。

要在添加和刪除每個字符時發送整個innerHTML，則意味着通過websocket發送大量數據，這會導致性能下降和速度降低。 發送附加數據不是一種選擇，因為我們不知道數據在div元素中的什么位置被附加，刪除或編輯。

請注意，使用鍵盤並不是一個客戶端可以更改其網頁副本的HTML內容的唯一方法。 客戶端使用javascript會根據一些活動來更改所需div元素的數據。

現在，我需要知道如何才能通過websocket發送准確的更改信息，即使是最微小的更改也可以獲取實時體驗。

PS我打算不使用任何現有的模塊，如Share.js，但歡迎提出建議。

Answer 1

這實際上不是一個“問題”，而是一個討論，將是“頭腦風暴”主題。 同樣，它是基於觀點的，因為沒有一種特定的方法可以討論如此廣泛的話題。

但是，我會抓住機會，並以純正的恕我直言的方式為我提供解決方法（很抱歉如此個人化）：

• 文本版本控制 -一種跟蹤文本版本的方法，類似於git，但是使用字符位置而不是行。 每個可編輯的文本都應受版本控制，應該有一個“主”將內容合並，並通知客戶端新版本。 在客戶端，應該以與服務器合並相同的方式應用版本更改（提交）。 關於提交順序。
• 結構更新 -這略有不同，因為結構更新僅涉及HTML結構，並且不需要版本控制（仍然有可能需要版本控制，或者至少需要一些操作歷史，並且涉及競速條件）。 編輯結構會將此類更改通知服務器。 它應確保所有客戶端在結構上都“在同一頁上”。
• 引用 -這可能很難。 引用HTML元素可能非常簡單（選擇器），但是有一個復雜性-例如，當<ul>包含許多<li> ，按索引引用每個元素-足夠公道，但是如果在兩者之間放置新元素呢？ 那會弄亂參考。 因此，引用應該是唯一的，並且完全取決於服務器將決定的同步ID。 您需要保留所有引用的列表以及指向html元素的指針，因此很容易直接訪問它們。
• 服務器<>客戶策略 。 如果您完全在談論同步體驗，那么您必須遵循權威的交流策略。 只有服務器真正地決定事情，而客戶端渲染並僅提供一些輸入（請求）。 例如，當客戶想要將元素添加到HTML中時，他發送請求，然后服務器決定它，然后將其插入，一旦插入，它將發布該事件，然后元素將出現在客戶上，然后他們可以編輯該內容元件。 您可以通過“前進”來進一步增強它，而無需等待服務器，但這應該作為額外的層而不是主要邏輯的一部分來完成。
• 當一個客戶端在節點 （元素/文本）上工作時，應該是唯一可以在該節點上工作（防止沖突）的人。 提交將被視為“進行中”，並且應為單版本提交。 首先，您只能在用戶“完成”編輯文本或元素后進行更新。 之后再添加此類過程的實時可視功能。
• 您必須研究這將造成的流量。 使用版本控制和基於事件的元素編輯-這將非常有效，但是代價是服務器端實際上應該模擬整個DOM結構並進行合並和其他操作。

同樣，這主要是基於意見的答案，而且不是一個小話題，它涉及許多領域。 我認為用“純”和“好”的方法來瞄准目標，而不是“最快”的方法，可能會有更簡單的解決方案，但需要權衡。