Các thành phần không trạng thái của React 0.14 sẽ cung cấp các cải tiến hiệu suất mà không cầnComponentUpdate như thế nào?


8

Câu hỏi này cứ lặp đi lặp lại trong đầu tôi kể từ khi tôi đọc các ghi chú phát hành (và các quảng cáo liên quan khác) xung quanh React 0.14 - Tôi là một fan hâm mộ lớn của React và tôi nghĩ rằng các thành phần không trạng thái ( https: //facebook.github. io / Reac / blog / 2015/09/10 / Reac-v0.14-rc1.html # statless-function-thành phần ) là một ý tưởng tuyệt vời, để dễ viết các thành phần như vậy và để thể hiện trong mã ý định rằng những điều này các thành phần phải "thuần túy" về mặt hiển thị nhất quán cho cùng một dữ liệu đạo cụ.

Câu hỏi đặt ra là: làm thế nào để React có thể tối ưu hóa các chức năng thành phần không trạng thái này mà không bị mất toàn bộ và cho rằng các tham chiếu đạo cụ không chỉ bất biến ở chỗ chúng không nên bị thao túng trong thành phần, mà còn không bao giờ có thể thay đổi bên ngoài vòng đời thành phần? Lý do mà các thành phần "thông thường" (còn gọi là các thành phần trạng thái - nói cách khác, các thành phần đi qua toàn bộ vòng đời; thành phầnWillMount, getInitialState, v.v.) có chức năng "nênComponentUpdate" tùy chọn là React không cho rằng tất cả các đạo cụ và tài liệu tham khảo nhà nước là hoàn toàn bất biến. Sau khi các thành phần đã được kết xuất, một số thuộc tính của các tham chiếu đạo cụ có thể thay đổi và do đó, ví dụ "đạo cụ" tương tự có thể có các nội dung khác nhau sau này. Đây là một phần lý do tại sao có rất nhiều hứng thú đối với việc sử dụng các cấu trúc hoàn toàn bất biến và tại sao người ta nói rằng sử dụng Om với React có thể mang lại hiệu quả tuyệt vời; bởi vì các cấu trúc bất biến được sử dụng ở đó đảm bảo rằng bất kỳ trường hợp cụ thể nào của bất kỳ đối tượng nào cũng không bao giờ bị đột biến, do đó, nênComponentUpdate có thể thực hiện kiểm tra đẳng thức tham chiếu thực sự rẻ trên đạo cụ và trạng thái (http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ ).

Tôi đã cố gắng tìm hiểu thêm thông tin về điều này nhưng không có ở đâu cả. Tôi không thể hình dung được những cải tiến hiệu suất nào có thể được thực hiện xung quanh các thành phần không trạng thái mà không cho rằng dữ liệu đạo cụ sẽ bao gồm các loại bất biến .. có thể một số phân tích sơ bộ về các loại đạo cụ không bất biến để thử đoán xem "đạo cụ" và "nextProps" có đại diện cho cùng dữ liệu?

Tôi chỉ tự hỏi nếu có ai có bất kỳ thông tin bên trong hoặc một số hiểu biết sâu sắc về điều này. Nếu React bắt đầu yêu cầu các loại đạo cụ là "hoàn toàn bất biến" (cho phép so sánh bình đẳng tham chiếu để xác nhận rằng dữ liệu không thay đổi) thì tôi nghĩ đó sẽ là một bước tiến lớn, nhưng nó cũng có thể là một thay đổi lớn.

Câu trả lời:


4

Có một vấn đề github trong dự án phản ứng về chính xác điều này.

Theo nhận xét vấn đề github này :

Đối với các thành phần phức tạp, việc xác định ShouldComponentUpdate (ví dụ: kết xuất thuần túy) thường sẽ vượt quá lợi ích hiệu suất của các thành phần không trạng thái. Các câu trong tài liệu gợi ý về một số tối ưu hóa trong tương lai mà chúng tôi đã lên kế hoạch, theo đó chúng tôi sẽ không phân bổ một thể hiện nội bộ cho các thành phần chức năng không trạng thái (chúng tôi sẽ chỉ gọi hàm). Chúng tôi cũng có thể không tiếp tục giữ đạo cụ, vv Tối ưu hóa nhỏ. Chúng tôi không nói về các chi tiết trong tài liệu vì các tối ưu hóa chưa thực sự được triển khai (các thành phần không trạng thái mở ra cánh cửa cho các tối ưu hóa này).

và từ một trả lời khác từ cùng một cộng tác viên:

Có các cuộc thảo luận về việc có một cờ PureRender mà bạn có thể thiết lập trên hàm hoặc cho phép nó tham gia vào vòng đời nênUpdate, nhưng hiện tại điều đó không được thực hiện. Hiện tại, các chức năng không trạng thái không thể hoàn toàn kết xuất.

cuối cùng từ nhận xét này, chúng tôi nhận được câu trả lời cho câu hỏi của bạn:

chúng tôi không thực hiện kết xuất hoàn toàn theo mặc định, nhưng chúng tôi có thể cung cấp một cách để bạn chọn tham gia trong tương lai.

Vì vậy, chúng tôi sẽ phải xem họ sẽ cho phép chúng tôi chọn tham gia vào 'purRender' :)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.