Sự khác biệt thực tế giữa redux và máy trạng thái (ví dụ: xstate) là gì?

Tôi đang nghiên cứu về một ứng dụng front-end có độ phức tạp trung bình. Tại thời điểm này, nó được viết bằng javascript thuần túy, nó có rất nhiều thông báo dựa trên sự kiện khác nhau kết nối một số phần chính của ứng dụng này.

Chúng tôi quyết định rằng chúng tôi cần triển khai một số loại vùng chứa trạng thái cho ứng dụng này trong phạm vi tái cấu trúc thêm. Trước đây tôi đã có một số kinh nghiệm với redux và ngrx store (thực sự tuân theo các nguyên tắc tương tự).

Redux là một lựa chọn cho chúng tôi, nhưng một trong những nhà phát triển đã đề xuất sử dụng thư viện dựa trên máy trạng thái, cụ thể là thư viện xstate .

Tôi chưa bao giờ làm việc với xstate, vì vậy tôi thấy nó thú vị và bắt đầu đọc tài liệu và xem các ví dụ khác nhau. Trông có vẻ đầy hứa hẹn và mạnh mẽ, nhưng tại một số thời điểm tôi hiểu rằng tôi không thấy bất kỳ sự khác biệt đáng kể nào giữa nó và redux.

Tôi đã dành hàng giờ để cố gắng tìm câu trả lời hoặc bất kỳ thông tin nào khác để so sánh xstate và redux. Tôi không tìm thấy bất kỳ thông tin rõ ràng nào, ngoại trừ một số bài báo như "chuyển từ redux sang máy trạng thái" hoặc liên kết đến các thư viện tập trung vào việc sử dụng redux và xstate cùng nhau (khá lạ).

Nếu ai đó có thể mô tả sự khác biệt hoặc cho tôi biết khi nào các nhà phát triển nên chọn xstate - bạn được hoan nghênh.

Tôi đã tạo XState, nhưng tôi sẽ không cho bạn biết có nên sử dụng cái này thay cho cái kia hay không; điều đó phụ thuộc vào nhóm của bạn. Thay vào đó, tôi sẽ cố gắng làm nổi bật một số điểm khác biệt chính.

• Redux về cơ bản là một vùng chứa trạng thái, nơi các sự kiện (được gọi là hành động trong Redux) được gửi đến một trình giảm bớt trạng thái cập nhật.
• XState cũng là một container nhà nước, nhưng nó tách trạng thái hữu hạn (ví dụ "loading", "success") từ "trạng thái vô hạn", hoặc bối cảnh (ví dụ items: [...]).
• Redux không chỉ định cách bạn xác định các bộ giảm tốc của mình. Chúng là các hàm đơn giản trả về trạng thái tiếp theo cho trạng thái hiện tại và sự kiện (hành động).
• XState là một "rút gọn với các quy tắc" - bạn xác định chuyển đổi hợp pháp giữa các trạng thái hữu hạn do các sự kiện và cũng như các hành động nào nên được thực hiện trong quá trình chuyển đổi (hoặc khi nhập / thoát khỏi một trạng thái)
• Redux không có một cách tích hợp để xử lý các tác dụng phụ. Có nhiều tùy chọn cộng đồng, như redux-thunk, redux-saga, v.v.
• XState làm cho các hành động (tác dụng phụ) được khai báo và rõ ràng - chúng là một phần của State đối tượng được trả về mỗi lần chuyển đổi (trạng thái hiện tại + sự kiện).
• Redux hiện không có cách nào để hình dung sự chuyển đổi giữa các trạng thái, vì nó không phân biệt giữa trạng thái hữu hạn và vô hạn.
• XState có trình hiển thị: https://statecharts.github.io/xstate-viz , khả thi do tính chất khai báo.
• Logic / hành vi ngầm định được đại diện trong các bộ giảm Redux không thể được tuần tự hóa một cách khai báo (ví dụ: trong JSON)
• Các định nghĩa máy của XState, đại diện cho logic / hành vi, có thể được tuần tự hóa thành JSON và đọc từ JSON. Điều này làm cho hành vi rất linh hoạt và có thể định cấu hình bằng các công cụ bên ngoài.
• Redux không hoàn toàn là một máy trạng thái.
• XState tuân thủ nghiêm ngặt đặc điểm kỹ thuật W3C SCXML: https://www.w3.org/TR/scxml/
• Redux dựa vào nhà phát triển để ngăn chặn các trạng thái không thể theo cách thủ công.
• XState sử dụng các biểu đồ trạng thái để xác định một cách tự nhiên các ranh giới để xử lý các sự kiện, ngăn chặn các trạng thái không thể xảy ra và có thể được phân tích tĩnh.
• Redux khuyến khích sử dụng một cửa hàng nguyên tử duy nhất, "toàn cầu".
• XState khuyến khích sử dụng phương pháp tiếp cận giống mô hình Actor, nơi có thể có nhiều phiên bản trạng thái / "dịch vụ" phân cấp giao tiếp với nhau.

Tôi sẽ thêm nhiều điểm khác biệt chính vào tài liệu trong tuần này.

Máy trạng thái không yêu cầu (buộc) bạn phải có luồng dữ liệu đơn hướng. Nó không liên quan gì đến luồng dữ liệu. Nó thiên về hạn chế thay đổi trạng thái và chuyển đổi trạng thái . Vì vậy, nói chung chỉ một số phần của ứng dụng sẽ được thiết kế với máy trạng thái, chỉ và chỉ khi bạn cần hạn chế / cấm một số thay đổi trạng thái và bạn quan tâm đến quá trình chuyển đổi.

Lưu ý rằng với các máy trạng thái, nếu vì lý do nào đó (phụ thuộc API bên ngoài, v.v.), có khả năng ứng dụng có thể bị khóa ở trạng thái không thể chuyển sang trạng thái khác vì các ràng buộc, bạn phải giải quyết nó.

Nhưng nếu bạn chỉ quan tâm đến chính trạng thái ứng dụng cuối cùng, thay vì chuyển đổi trạng thái và các ràng buộc trạng thái không quan trọng, thì tốt hơn bạn không nên sử dụng máy trạng thái và trực tiếp cập nhật trạng thái ( bạn vẫn có thể bọc trạng thái trong bản cập nhật lớp Singleton thông qua Các lớp hành động ).

Mặt khác, Redux là khung kiến ​​trúc đơn hướng . Các kiến ​​trúc đơn hướng buộc bạn phải có một hướng duy nhất của luồng dữ liệu. Trong Redux, nó bắt đầu bằng User->View->(Action)->Store->Reducer->(Middleware)->Store->(State)->View. Giống như State Machines, bạn có thể kích hoạt các tác dụng phụ với Middleware trong Redux. Bạn có thể hạn chế / cấm chuyển trạng thái nếu muốn. Khác với State Machine , Redux buộc luồng dữ liệu đơn hướng, thuần túy ! các chức năng giảm thiểu, các đối tượng trạng thái bất biến, trạng thái ứng dụng có thể quan sát đơn lẻ.