React-Redux: Nên giữ tất cả các trạng thái thành phần trong Redux Store


88

Giả sử tôi có một chuyển đổi đơn giản:

Khi tôi nhấp vào nút, thành phần Màu thay đổi giữa màu đỏ và xanh lam

Tôi có thể đạt được kết quả này bằng cách làm điều gì đó như thế này.

index.js

Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red

containerr.js

connect(mapStateToProps)(indexPage)

action_creator.js

function changeColor(){
 return {type: 'CHANGE_COLOR'}
}

Reduceer.js

switch(){
case 'CHANGE_COLOR':
return {color: true}

nhưng đây là một đống mã để viết cho một thứ gì đó mà tôi có thể đạt được trong 5 giây với jQuery, một số lớp và một số css ...

Vì vậy, tôi đoán những gì tôi thực sự đang hỏi là, tôi đang làm gì sai ở đây?


6
react-redux không được bán dưới dạng thứ gì đó ngắn hơn jquery. Nó chắc chắn cần một số mã để đưa nó lên và chạy.
zerkms

1
Hãy xem tại đây: github.com/rackt/redux/issues/1287 có rất nhiều cuộc thảo luận hay về chủ đề này.
m0meni

1
cảm ơn @ AR7 thats perfect
l2silver 10/02/16

1
@ l2silver không sao. Về cơ bản, ý tưởng là nếu màu sắc của thành phần đó không quan trọng đối với bất kỳ ai khác, chỉ cần giữ trạng thái đó bên trong chính thành phần đó.
m0meni

2
vấn đề mà AR7 đề cập đã chuyển đi: github.com/reactjs/redux/issues/1287
ptim

Câu trả lời:


152

Redux chủ yếu dành cho "trạng thái ứng dụng". Đó là, bất cứ điều gì liên quan đến logic ứng dụng của bạn. Chế độ xem được xây dựng trên nó là sự phản ánh của trạng thái đó, nhưng không phải sử dụng riêng vùng chứa trạng thái đó cho mọi thứ mà nó thực hiện.

Đơn giản chỉ cần hỏi những câu hỏi sau: Trạng thái này có quan trọng đối với phần còn lại của ứng dụng không? Các phần khác của ứng dụng có hoạt động khác dựa trên trạng thái đó không? Trong nhiều trường hợp nhỏ, đó sẽ không phải là trường hợp. Lấy menu thả xuống: Việc nó mở hoặc đóng có thể sẽ không ảnh hưởng đến các phần khác của ứng dụng. Vì vậy, việc kết nối nó với cửa hàng của bạn có thể là quá mức cần thiết. Đó chắc chắn là một lựa chọn hợp lệ, nhưng không thực sự mang lại cho bạn bất kỳ lợi ích nào. Tốt hơn hết bạn nên sử dụng this.statevà gọi nó là một ngày.

Trong ví dụ cụ thể của bạn, màu sắc của nút đó có được chuyển đổi để tạo ra bất kỳ sự khác biệt nào trong các phần khác của ứng dụng không? Nếu đó là một loại nút bật / tắt toàn cầu nào đó cho một phần chính của ứng dụng của bạn, thì nó chắc chắn thuộc về cửa hàng. Nhưng nếu bạn chỉ chuyển đổi một màu nút khi bạn nhấp vào nút, bạn có thể để trạng thái màu được xác định cục bộ. Hành động nhấp vào nút có thể có các hiệu ứng khác yêu cầu cử hành động, nhưng điều đó tách biệt với câu hỏi đơn giản về màu sắc của nó.

Nói chung, hãy cố gắng giữ trạng thái ứng dụng của bạn càng nhỏ càng tốt. Bạn không cần phải nhét mọi thứ vào đó. Làm điều đó khi bạn phải làm hoặc giữ một thứ gì đó ở đó rất có ý nghĩa. Hoặc nếu nó làm cho cuộc sống của bạn dễ dàng hơn khi sử dụng Công cụ Dev. Nhưng đừng quá tải tầm quan trọng của nó.


Này, tôi biết sẽ không bao giờ có câu trả lời chắc chắn cho câu hỏi này, nhưng tôi nghĩ logic của bạn ở đây rất hợp lý
l2silver

3
Thành thật mà nói, tôi không thực sự hiểu điểm để sử dụng thứ flux / redux đó ở tất cả. Vấn đề với mô hình điều khiển sự kiện là gì?
jayarjo

IMO, nó không phải là câu trả lời hoàn hảo. Nó phụ thuộc. Lưu trữ trạng thái ui vào trạng thái phản ứng sẽ làm cho kho lưu trữ redux trở nên sạch sẽ nhưng nó sẽ tạo ra thành phần phi chức năng rất khó kiểm tra. Trong khi lưu trữ trạng thái ui vào trạng thái phản ứng sẽ khiến nhà phát triển phải nỗ lực rất nhiều, vì chúng ta phải viết thêm các bộ giảm bớt. Tuy nhiên, có nhiều gói có thể giúp bạn đặt trạng thái ui của mình dễ dàng hơn nhiều để lưu trữ redux, hãy xem redux.js.org/docs/faq/OrganizingState.html để biết thêm chi tiết.
Ron

19

Câu hỏi thường gặp về Redux: Trạng thái tổ chức
phần này của tài liệu chính thức của redux đã trả lời tốt câu hỏi của bạn.

Sử dụng trạng thái thành phần cục bộ là tốt . Là một nhà phát triển, nhiệm vụ của bạn là xác định loại trạng thái nào tạo nên ứng dụng của bạn và nơi mỗi phần của trạng thái sẽ tồn tại. Tìm một số dư phù hợp với bạn và đồng hành với nó.

Một số quy tắc chung để xác định loại dữ liệu nào nên được đưa vào Redux:

  • Các phần khác của ứng dụng có quan tâm đến dữ liệu này không?
  • Bạn có cần phải tạo thêm dữ liệu có nguồn gốc dựa trên dữ liệu gốc này không?
  • Có phải cùng một dữ liệu được sử dụng để điều khiển nhiều thành phần không?
  • Có giá trị nào đối với bạn khi có thể khôi phục trạng thái này đến một thời điểm nhất định (tức là gỡ lỗi du hành thời gian) không?
  • Bạn có muốn lưu dữ liệu vào bộ nhớ cache (tức là sử dụng trạng thái nếu nó đã ở đó thay vì yêu cầu lại)?

6

Với mục đích làm nổi bật liên kết tuyệt vời do @ AR7 cung cấp và vì liên kết đó đã di chuyển trở lại một thời gian:

Sử dụng React cho trạng thái tạm thời không quan trọng đối với ứng dụng trên toàn cầu và không thay đổi theo những cách phức tạp. Ví dụ: chuyển đổi trong một số phần tử giao diện người dùng, trạng thái nhập biểu mẫu. Sử dụng Redux cho trạng thái quan trọng trên toàn cầu hoặc bị thay đổi theo những cách phức tạp. Ví dụ: người dùng đã lưu trong bộ nhớ cache hoặc một bản nháp bài đăng.

Đôi khi bạn sẽ muốn chuyển từ trạng thái Redux sang trạng thái React (khi việc lưu trữ thứ gì đó trong Redux trở nên khó xử) hoặc ngược lại (khi nhiều thành phần hơn cần có quyền truy cập vào một số trạng thái đã từng là cục bộ).

Quy tắc ngón tay cái là: làm bất cứ điều gì ít khó xử hơn.

Dan Abramov: https://github.com/reactjs/redux/issues/1287#issuecomment-175351978


-7

Có, bạn nên cố gắng lưu trữ tất cả trạng thái thành phần trong Redux . Nếu làm vậy, bạn sẽ được hưởng lợi từ nhiều tính năng của Redux như gỡ lỗi du hành thời gian và báo cáo lỗi có thể phát lại. Nếu không, các tính năng đó hoàn toàn có thể không sử dụng được .

Bất cứ lúc nào bạn không lưu trữ thay đổi trạng thái thành phần trong Redux, thay đổi đó hoàn toàn bị mất khỏi chồng các thay đổi của Redux và giao diện người dùng ứng dụng của bạn sẽ không đồng bộ với cửa hàng. Nếu điều này không quan trọng với bạn thì hãy tự hỏi tại sao lại sử dụng Redux? Ứng dụng của bạn sẽ ít phức tạp hơn nếu không có nó!

Vì lý do hiệu suất, bạn có thể muốn quay lại this.setState()bất kỳ điều gì có thể thực hiện nhiều hành động lặp đi lặp lại. Ví dụ: lưu trữ trạng thái của trường đầu vào trong Redux mỗi khi người dùng nhập khóa có thể dẫn đến hiệu suất kém. Bạn có thể giải quyết vấn đề này bằng cách coi nó như một giao dịch: sau khi hành động của người dùng được "cam kết", hãy lưu trạng thái cuối cùng trong Redux.

Bài đăng ban đầu của bạn đề cập đến cách Redux là một "địa ngục của rất nhiều mã để viết." Có nhưng bạn có thể sử dụng trừu tượng cho các mẫu phổ biến như trạng thái thành phần cục bộ.


Cải thiện gỡ lỗi là một mục tiêu hữu ích và là một tính năng hay của redux, nhưng tôi nghĩ rằng tỷ lệ tín hiệu trên nhiễu cũng rất quan trọng. Người ta có thể ghi lại mọi biến trong một cơ sở mã, nhưng điều đó sẽ thêm rất nhiều mã bổ sung làm cho mã thực tế khó đọc hơn và việc ghi nhật ký sẽ khó tìm kiếm. Tôi nghĩ rằng điều tương tự cũng áp dụng cho việc sử dụng redux. Có tất cả các trạng thái trong redux có thể cải thiện việc gỡ lỗi, nhưng có một khoản chi phí bổ sung trong mã và phần tóm tắt có thể khiến mã khó đọc hơn và thậm chí làm cho một số tác vụ gỡ lỗi khó hơn. (Và khi các công cụ Redux dev sụp đổ, nhiều lợi ích gỡ lỗi bị mất.)
JD Sandifer

1
Vậy tại sao lại sử dụng Redux? Nếu bạn không đặt mọi thứ vào Redux, bạn sẽ mất tất cả các tính năng, chẳng hạn như devtools. Nó thực sự là tất cả hoặc không có gì. Nếu bạn sử dụng setState () cho menu thả xuống như trong câu trả lời trên cùng cho bài đăng này, bạn không thể sử dụng devtools để gỡ lỗi bất kỳ sự cố nào mà người dùng của bạn có thể gặp phải trong menu thả xuống. Còn tệ hơn khi bạn sử dụng setState () cho lớp phủ vì không có cách nào để du hành thời gian trước và sau khi lớp phủ được hiển thị. Rắc setState () ở đây và rất dễ xảy ra lỗi vì nhà phát triển phải liên tục suy nghĩ về những gì có thể bị hỏng.
kumar303 27/09/09

Như một câu trả lời cụ thể hơn, việc ghi lại mọi biến trong cơ sở mã không phải là một phép ẩn dụ hữu ích vì câu hỏi là về việc sử dụng this.setState()hoặc dispatch(action...). Một người không cần phải sử dụng this.setState()ở mọi nơi nhưng khi bạn cần, đề xuất của tôi là sử dụng Redux thay thế cho 99% trường hợp, giảm về this.setState()1% dựa trên mối quan tâm về hiệu suất.
kumar303

Việc ghi nhật ký mọi biến đối với tôi dường như tương tự như việc đưa mọi thứ vào Redux và không thể sử dụng được như một quy tắc chung. Để lại một số thứ ra khỏi Redux không phủ nhận các tính năng cho tất cả những gì trong Redux chừng nào nhà nước được tách ra. Tức là tôi vẫn có thể gỡ lỗi logic cuộc gọi API của mình được chuyển qua Redux ngay cả khi trạng thái của hộp lựa chọn không phải là. OP có một điểm - nó yêu cầu nhiều mã hơn ở nhiều nơi để sử dụng Redux và có thể điều đó không được chứng minh trong ví dụ cụ thể mà họ đã liệt kê.
JD Sandifer

Thực ra bạn có thể không gỡ lỗi được logic API của mình. Đó là quan điểm của tôi. Thực sự rất khó để lường trước các tình huống mà bạn sẽ phá vỡ việc du hành thời gian, vì vậy tốt hơn là chỉ cần đặt tất cả trạng thái (bao gồm cả trạng thái hộp lựa chọn) trong Redux cho đến khi có vấn đề về hiệu suất.
kumar303
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.