2015-06-08 12 views
5

Om, trình bao bọc clojurescript của React, được cho là rất nhanh vì nó thúc đẩy bất biến. Tôi không thể hiểu cấu trúc dữ liệu liên tục có thể trợ giúp như thế nào ở đây.Làm thế nào để cấu trúc dữ liệu liên tục giúp Om nhanh hơn

Điều tôi đã hiểu là trạng thái ứng dụng là một nguyên tử. Trạng thái này được chuyển tới các hàm (các thành phần om) trả về các nút DOM ảo, để tạo ra một "bản vá" về sự khác biệt giữa DOM ảo hiện tại và trạng thái trước đó của nó tốt hơn nhiều sau đó hoạt động trực tiếp trên DOM thực tế.

Nhưng nơi cấu trúc dữ liệu liên tục có thể trợ giúp ở đây?

(def app-state (atom {:foo {:counter 0})) 
(om/root click-counter app-state {:target ...}) 

ví dụ click-counter làm cho một nút mà khi nhấn vào increments quầy. Vì vậy, Chức năng chuyển trông như thế này:

(dom/button #js {:onClick #(om/transact! app [:foo :counter] inc)} 
      (str "clicked " (-> app :foo :counter) " times")) 

tôi đã hiểu thế này: khi onClick là clojurescript thực hiện tạo ra một bản đồ mới (rất hiệu quả) như thế này:

{:foo {:counter 1}} 

app-state nay chỉ vào bản đồ mới . Tại thời điểm này, Om biết rằng trạng thái được thay đổi bởi vì nó chỉ là vấn đề kiểm tra bình đẳng.

Vấn đề ở đây là Om vẫn nên tính toán sự khác biệt giữa toàn bộ DOM ảo cũ và phiên bản mới. Nó không biết rằng chỉ cần truy cập được thay đổi.

Lỗi của tôi ở đâu?

Trả lời

4

Khi trạng thái ứng dụng được lưu trữ trong cấu trúc cây cố định như bản đồ, ngay lập tức hiển thị các phần của cây trạng thái không thay đổi và không cần cập nhật. Điều này là do bất kỳ thay đổi nào đối với đứa trẻ đều thay đổi phụ huynh. Với những thay đổi cấu trúc dữ liệu có thể thay đổi cho trẻ em không cần phải thay đổi cha mẹ.

Vì vậy, nếu tiểu bang của bạn trông như thế này:

{:part1 [1 2 3 4] 
:part2 [:a :b]} 

và bạn thực hiện một trạng thái mới bằng cách thêm một cái gì đó trong part2:

{:part1 [1 2 3 4] 
:part2 [:a :b :c]} 

thì hàm so sánh có thể nhìn và thấy rằng giá trị trong : part1 của trạng thái cũ và mới là cùng một đối tượng và do đó không thể thay đổi bất kỳ trạng thái lồng nhau nào vì nó không thay đổi.

+0

Cảm ơn. Vì vậy, chỉ khi một kiểm tra bình đẳng trên một nút không thành công hơn là một tái render cuối cùng của trẻ em của nó là bắt buộc. – agori

+1

Nếu sự bình đẳng thất bại thì có thể yêu cầu nhập lại, mặc dù có thể không, bạn có thể thay đổi nó và sau đó thay đổi lại. Nếu bình đẳng vượt qua thì bạn hoàn toàn * không * cần phải cập nhật nó. –

+0

Vấn đề tôi thấy là với cấu trúc dữ liệu phẳng lớn như vectơ của hàng nghìn phần tử (có thể là ứng dụng giống như excel) và bạn chỉ thay đổi một phần tử của vector: '(def cells (atom (into [] (replicate 1000 {: val: empty})))) 'và sau đó' (hoán đổi! (Các tế bào assoc-in [1: val] 10)) '. Điều này làm cho Om kiểm tra tất cả các phần tử vì gốc của cấu trúc dữ liệu bị thay đổi và bạn không biết ô nào đã được sửa đổi. Vì vậy, có vẻ như tất cả mọi thứ là hoàn toàn phụ thuộc vào cách bạn quyết định cấu trúc nhà nước ứng dụng của bạn, cho rằng Om không hoạt động tốt với cấu trúc dữ liệu phẳng lớn. – agori

Các vấn đề liên quan