準確的目的是什麼做出反應DOM虛擬

DOM操作是非常昂貴的

但最終反應也做的DOM操作。我們無法使用虛擬DOM生成視圖。
摺疊整個DOM並構建它會影響用戶體驗。

我從來沒有這樣做，大部分我所做的是更改所需的子節點（而不是摺疊整個父節點）或附加由JS生成的HTML代碼。

例子：

當用戶向下滾動，我們追加職位，以父元素，甚至反應也必須這樣做，以同樣的方式。沒有人爲此而折戟。
當用戶對帖子發表評論時，我們會在該特定帖子評論列表中添加div（評論元素（HTML code））。我認爲對於

3）「版本比較」算法來檢查變更沒有一個塌陷整個帖子（DOM）：

爲什麼我們需要一個算法來檢查變更。例子：如果我有100個職位，只要用戶點擊某個帖子的編輯按鈕，我做如下

$(".postEdit").click(function(){ 
     var post_id = $(this).data("postid"); 
     //do some Ajax and DOM manipulation to that particular post. 
    })

我說的是DOM改變特定的元素，那麼如何版本比較幫助？

我以錯誤的方式思考？如果是這樣，請糾正我。

來源

2016-12-31 Joshna

具有通的讀** [此答案]（http://stackoverflow.com/a/37012883/2902660）**到： _ [爲什麼React的Virtual DOM概念被認爲比髒模型檢查更高效]（http://stackoverflow.com/q/21109361/2902660）_ – Pineda

當然，當人們需要更新單個元素時，他們並不傾向於崩潰並重新創建整個DOM。相反，最好的做法是重建你需要的元素。但是如果用戶採取實際影響大量元素的操作呢？喜歡它，他們會發布帖子或其他內容，但您希望在帖子中反映該信息，也可以在頁面的其他位置進行明星統計。隨着應用程序變得足夠複雜，更改需要更改頁面的所有部分變得非常複雜且容易出錯。另一位開發人員可能不知道頁面上的其他位置有「星號」，並且會忘記更新它。

如果你可以重建整個DOM，該怎麼辦？如果你寫了你的渲染方法並存儲你的狀態，以至於在任何時候都可以肯定地從頭開始渲染整個頁面？這消除了很多這些痛點，但顯然你會失去手動修改DOM部分所帶來的所有性能提升。

反應和虛擬dom給你兩全其美。您可以獲得經過優化的DOM更新，但作爲開發人員，您不必爲整個應用程序保留一個心智模型，並記住需要針對任何給定的用戶或網絡輸入更改哪些內容。虛擬dom也可能比你更有效地實現這些變化，從字面上只重建你需要的元素。在某些情況下，你可能會重建的不僅僅是「以防萬一」。

希望這種說法有道理！

來源

2016-12-31 16:21:45