Redux - nhiều cửa hàng, tại sao không?

Lưu ý: Tôi đã đọc các tài liệu cho Redux (Baobab cũng vậy) và tôi đã thực hiện một phần chia sẻ công bằng về Google và thử nghiệm.

Tại sao nó được đề xuất mạnh mẽ rằng một ứng dụng Redux chỉ có một cửa hàng?

Tôi hiểu những ưu / nhược điểm của thiết lập một cửa hàng so với thiết lập nhiều cửa hàng ( Có nhiều câu hỏi và trả lời về SO về chủ đề này ).

IMO, quyết định kiến ​​trúc này thuộc về các nhà phát triển ứng dụng dựa trên nhu cầu của dự án của họ. Vậy tại sao nó lại được đề xuất mạnh mẽ cho Redux, gần như đến mức nghe có vẻ bắt buộc ( mặc dù không có gì ngăn cản chúng tôi làm nhiều cửa hàng )?

EDIT: phản hồi sau khi chuyển đổi sang một cửa hàng

Sau một vài tháng làm việc với redux về những gì nhiều người sẽ coi là một SPA phức tạp, tôi có thể nói rằng cấu trúc cửa hàng duy nhất là một niềm vui thuần túy để làm việc.

Một vài điểm có thể giúp người khác hiểu tại sao một cửa hàng so với nhiều cửa hàng là một câu hỏi tranh luận trong nhiều trường hợp sử dụng:

• thật đáng tin cậy : chúng tôi sử dụng các công cụ chọn để tìm hiểu trạng thái ứng dụng và thu được thông tin liên quan đến ngữ cảnh. Chúng tôi biết rằng tất cả các dữ liệu cần thiết là trong một cửa hàng duy nhất. Nó tránh tất cả các câu hỏi về vấn đề nhà nước có thể được.
• thật nhanh : cửa hàng của chúng tôi hiện có gần 100 hộp giảm tốc, nếu không muốn nói là nhiều hơn. Ngay cả ở số đó, chỉ một số ít bộ giảm tốc xử lý dữ liệu trên bất kỳ công văn nào, những cái khác chỉ trả về trạng thái trước đó. Lập luận rằng một cửa hàng khổng lồ / phức tạp ( nbr của bộ giảm tốc ) chậm là khá nhiều. Ít nhất chúng tôi đã không thấy bất kỳ vấn đề hiệu suất đến từ đó.
• gỡ lỗi thân thiện : mặc dù đây là một lập luận thuyết phục nhất để sử dụng toàn bộ redux, nhưng nó cũng dành cho một cửa hàng so với nhiều cửa hàng. Khi xây dựng một ứng dụng bạn nhất định có lỗi trạng thái trong quy trình ( lỗi lập trình viên ), điều đó là bình thường. PITA là khi các lỗi đó mất hàng giờ để gỡ lỗi. Nhờ vào một cửa hàng duy nhất ( và redux-logger ), chúng tôi chưa bao giờ dành quá vài phút cho bất kỳ vấn đề nào của nhà nước.

một vài gợi ý

Thách thức thực sự trong việc xây dựng cửa hàng redux của bạn là khi quyết định cách cấu trúc nó. Thứ nhất, vì thay đổi cấu trúc xuống đường chỉ là một nỗi đau lớn. Thứ hai, bởi vì phần lớn quyết định cách bạn sẽ sử dụng và truy vấn dữ liệu ứng dụng của bạn cho bất kỳ quy trình nào. Có rất nhiều gợi ý về cách cấu trúc một cửa hàng. Trong trường hợp của chúng tôi, chúng tôi thấy sau đây là lý tưởng:

{
  apis: {     // data from various services
    api1: {},
    api2: {},
    ...
  }, 
  components: {} // UI state data for each widget, component, you name it 
  session: {} // session-specific information
}

Hy vọng thông tin phản hồi này sẽ giúp đỡ người khác.

EDIT 2 - công cụ lưu trữ hữu ích

Đối với những người bạn đã tự hỏi làm thế nào để "dễ dàng" quản lý một cửa hàng , điều này có thể nhanh chóng trở nên phức tạp. Có một công cụ giúp cô lập các phụ thuộc cấu trúc / logic của cửa hàng của bạn.

Có Normalizr chuẩn hóa dữ liệu của bạn dựa trên lược đồ. Sau đó, nó cung cấp một giao diện để làm việc với dữ liệu của bạn và tìm nạp các phần khác của dữ liệu của bạn id, giống như một Từ điển.

Không biết bình thường vào thời điểm đó, tôi đã xây dựng một cái gì đó dọc theo cùng một dòng. quan hệ-json lấy một lược đồ và trả về giao diện dựa trên Bảng ( giống như một cơ sở dữ liệu ). Ưu điểm của mối quan hệ-json là cấu trúc dữ liệu của bạn tự động tham chiếu các phần khác của dữ liệu của bạn ( về cơ bản, bạn có thể di chuyển dữ liệu của mình theo bất kỳ hướng nào, giống như các đối tượng JS bình thường ). Nó không chín chắn như Normalizr, nhưng tôi đã sử dụng nó thành công trong sản xuất vài tháng nay.

Có những trường hợp cạnh khi bạn có thể sử dụng nhiều cửa hàng (ví dụ: nếu bạn gặp vấn đề về hiệu suất với việc cập nhật danh sách hàng ngàn mặt hàng trên màn hình cùng một lúc nhiều lần trong một giây). Điều đó nói rằng đó là một ngoại lệ và trong hầu hết các ứng dụng, bạn không bao giờ cần nhiều hơn một cửa hàng.

Tại sao chúng ta nhấn mạnh điều này trong các tài liệu? Bởi vì hầu hết mọi người đến từ nền Flux sẽ cho rằng nhiều cửa hàng là giải pháp để tạo mã cập nhật theo mô-đun. Tuy nhiên Redux có một giải pháp khác cho việc này: thành phần chất khử.

Có nhiều bộ giảm tốc được chia thành cây giảm tốc là cách bạn giữ các bản cập nhật theo mô-đun trong Redux. Nếu bạn không nhận ra điều này và đi đến nhiều cửa hàng mà không hiểu đầy đủ về thành phần bộ giảm tốc, bạn sẽ bỏ lỡ nhiều lợi ích của kiến ​​trúc cửa hàng đơn Redux:

• Sử dụng thành phần bộ giảm tốc giúp dễ dàng thực hiện "cập nhật phụ thuộc" một waitForcách thông minh bằng cách viết một bộ giảm tốc gọi thủ công các bộ giảm tốc khác với thông tin bổ sung và theo một thứ tự cụ thể.

• Với một cửa hàng duy nhất, thật dễ dàng để duy trì, ngậm nước và đọc trạng thái. Kết xuất máy chủ và tìm nạp trước dữ liệu là không đáng kể vì chỉ có một bộ lưu trữ dữ liệu cần được điền và bù nước trên máy khách và JSON có thể mô tả nội dung của nó mà không phải lo lắng về ID hoặc tên của cửa hàng.

• Một cửa hàng duy nhất làm cho các tính năng du hành thời gian của Redux DevTools có thể. Nó cũng làm cho các tiện ích mở rộng cộng đồng như redux-undo hoặc redux-Optimist trở nên dễ dàng vì chúng hoạt động ở mức giảm. "Chất tăng cường giảm tốc" như vậy không thể được viết cho các cửa hàng.

• Một cửa hàng duy nhất đảm bảo rằng các đăng ký chỉ được gọi sau khi công văn được xử lý. Đó là, theo thời gian người nghe được thông báo, nhà nước đã được cập nhật đầy đủ. Với nhiều cửa hàng, không có sự đảm bảo như vậy. Đây là một trong những lý do Flux cần waitForcái nạng. Với một cửa hàng duy nhất, đây không phải là vấn đề bạn thấy ở nơi đầu tiên.

• Trên tất cả, nhiều cửa hàng là không cần thiết trong Redux (ngoại trừ các trường hợp cạnh hiệu suất mà trước tiên bạn phải lập hồ sơ). Chúng tôi coi đó là một điểm quan trọng trong các tài liệu để bạn được khuyến khích tìm hiểu thành phần bộ giảm tốc và các mẫu Redux khác thay vì sử dụng Redux như thể đó là Flux và mất lợi ích của nó.

Trong một số ứng dụng doanh nghiệp rất lớn với hàng trăm hoặc hàng nghìn bộ giảm tốc, thường rất hữu ích khi nghĩ về các khu vực khác nhau của ứng dụng là các ứng dụng hoàn toàn riêng biệt. Trong những trường hợp đó (nơi thực sự là nhiều ứng dụng chia sẻ một tên miền), tôi sử dụng nhiều cửa hàng.

Ví dụ: tôi có xu hướng coi các khu vực chức năng phổ biến sau là các ứng dụng riêng biệt:

• quản trị viên
• Bảng điều khiển vis / dữ liệu
• Quản lý thanh toán và mua hàng
• Đội ngũ tài khoản doanh nghiệp / quản lý cấp phép

Nếu bất kỳ thứ gì trong số đó là nhỏ, chỉ cần giữ chúng như một phần của ứng dụng chính. Nếu chúng phát triển rất lớn (như một số công cụ quản lý & phân tích tài khoản doanh nghiệp làm), hãy tách chúng ra.

Cách tốt nhất để quản lý các ứng dụng rất lớn là coi chúng như một thành phần của nhiều ứng dụng nhỏ hơn.

Nếu ứng dụng của bạn ít hơn nói ~ 50 nghìn LỘC, có lẽ bạn nên bỏ qua lời khuyên này và thay vào đó hãy làm theo lời khuyên của Dan.

Nếu ứng dụng của bạn lớn hơn 1 triệu LỘC, có lẽ bạn nên tách ra các ứng dụng nhỏ, ngay cả khi bạn duy trì chúng trong một repo đơn âm.

Quyết định kiến ​​trúc này thuộc về các nhà phát triển ứng dụng dựa trên nhu cầu của dự án của họ

Bạn đang sống trong thế giới của riêng bạn. Tôi đang gặp gỡ những người sử dụng redux, bởi vì nó phổ biến, hàng ngày. Bạn thậm chí không thể tưởng tượng được có bao nhiêu dự án đã bắt đầu chuyển hướng mà không có bất kỳ quyết định nào. Tôi ghét cách tiếp cận redux nhưng phải sử dụng nó, bởi vì các nhà phát triển khác không biết gì khác. Nó chỉ là một bong bóng hoành tráng được thổi phồng lên bởi facebook.

• Nó không đáng tin cậy vì các bộ phận của cửa hàng không bị cô lập.
• Nó không hiệu quả vì bạn đang nhân bản và vượt qua hàm băm. Khi đột biến tăng trưởng một cách hợp lý - sự phức tạp tăng lên về mặt hình học. Bạn không thể sửa nó bằng cách tái cấu trúc bất kỳ bộ giảm tốc, bộ chọn, v.v. Bạn phải chia bộ ba của mình.
• Khi nó trở nên chậm, không ai muốn chia nó thành các ứng dụng riêng biệt với các cửa hàng riêng biệt. Không ai muốn chi tiền cho tái cấu trúc. Mọi người thường chuyển đổi một số thành phần thông minh thành bãi chứa và đó là nó. Bạn có biết những gì tương lai đang chờ đợi các nhà phát triển redux? Họ sẽ duy trì những địa ngục này.
• Nó không gỡ lỗi thân thiện . Thật khó để gỡ lỗi kết nối giữa các bộ phận gần như bị cô lập của cửa hàng. Thậm chí rất khó để phân tích số lượng của các kết nối này.

Hãy tưởng tượng rằng bạn có một số cửa hàng redux. Bạn sẽ phá vỡ luồng dữ liệu đơn hướng. Bạn sẽ ngay lập tức nhận ra có bao nhiêu kết nối giữa các cửa hàng bạn có. Bạn có thể bị các kết nối này, chiến đấu với deps tròn, vv

Cửa hàng bất biến duy nhất với dòng chảy một chiều không phải là thuốc tiên cho mọi bệnh. Nếu bạn không muốn duy trì kiến ​​trúc dự án, bạn sẽ phải chịu đựng.

Nhiều cửa hàng có thể hữu ích trong các trường hợp sử dụng sau 1. Nếu bạn có các thành phần lớn độc lập với nhau về cấu trúc dữ liệu, hành vi, bối cảnh ứng dụng. Cô lập các thành phần này giúp quản lý luồng dữ liệu và ứng dụng của bạn dễ dàng hơn. Nó cũng giúp phát triển độc lập và bảo trì các thành phần của bạn. 2. Vấn đề về hiệu suất: không phải là trường hợp sử dụng thông thường, nhưng nếu một số thành phần của bạn cập nhật rất thường xuyên và không có bất kỳ tác động nào đến các thành phần khác, có lẽ bạn có thể đến các cửa hàng khác nhau.

Đối với tất cả các trường hợp khác, bạn có thể không cần phải có nhiều cửa hàng. Như Dan nói, tạo ra các chế phẩm giảm thiểu chu đáo có thể chứng minh là giải pháp tốt hơn.

Tại sao chúng ta không thể sử dụng nhiều cửa hàng bằng cách sử dụng redux ????

Điều này là không cần thiết trong Redux vì sự phân tách giữa các miền dữ liệu đã đạt được bằng cách tách một bộ giảm tốc thành các bộ giảm nhỏ hơn.

Tôi có thể hoặc nên tạo nhiều cửa hàng? Tôi có thể nhập trực tiếp cửa hàng của mình và sử dụng nó trong các thành phần không?

Mẫu Flux ban đầu mô tả việc có nhiều cửa hàng lưu trữ trên mạng trong một ứng dụng, mỗi ứng dụng chứa một vùng dữ liệu miền khác nhau. Điều này có thể giới thiệu các vấn đề như cần phải có một cửa hàng, hãy đợi một cửa hàng khác để cập nhật.

Điều này là không cần thiết trong Redux vì sự phân tách giữa các miền dữ liệu đã đạt được bằng cách tách một bộ giảm tốc thành các bộ giảm nhỏ hơn.

Cũng như một số câu hỏi khác, có thể tạo nhiều cửa hàng Redux riêng biệt trong một trang, nhưng mẫu dự định là chỉ có một cửa hàng duy nhất. Có một cửa hàng duy nhất cho phép sử dụng Redux DevTools, giúp việc duy trì và bù nước dữ liệu trở nên đơn giản hơn và đơn giản hóa logic đăng ký.

Một số lý do hợp lệ để sử dụng nhiều cửa hàng trong Redux có thể bao gồm:

Giải quyết vấn đề về hiệu suất do cập nhật quá thường xuyên của một số phần của tiểu bang, khi được xác nhận bằng cách định hình ứng dụng. Cô lập một ứng dụng Redux như một thành phần trong một ứng dụng lớn hơn, trong trường hợp đó bạn có thể muốn tạo một cửa hàng cho mỗi phiên bản thành phần gốc. Tuy nhiên, việc tạo các cửa hàng mới không phải là bản năng đầu tiên của bạn, đặc biệt nếu bạn đến từ nền Flux. Trước tiên hãy thử thành phần giảm tốc và chỉ sử dụng nhiều cửa hàng nếu nó không giải quyết được vấn đề của bạn.

Tương tự, trong khi bạn có thể tham chiếu thể hiện cửa hàng của mình bằng cách nhập trực tiếp, đây không phải là mẫu được đề xuất trong Redux. Nếu bạn tạo một cá thể cửa hàng và xuất nó từ một mô-đun, nó sẽ trở thành một singleton. Điều này có nghĩa là sẽ khó khăn hơn khi cô lập ứng dụng Redux như một thành phần của ứng dụng lớn hơn, nếu điều này là cần thiết hoặc để bật kết xuất máy chủ, bởi vì trên máy chủ bạn muốn tạo các phiên bản cửa hàng riêng biệt cho mỗi yêu cầu.

tài liệu chính thức của redux

Có một cửa hàng trong Redux thực sự là những gì chúng tôi cần trong nhiều trường hợp, tôi đều sử dụng Redux và Flux và tin rằng Redux thực hiện công việc tốt hơn!

Đừng quên cửa hàng nằm trong Đối tượng JavaScript, vì vậy, trong khi bạn chỉ có một cửa hàng, nó có thể dễ dàng được mở rộng và sử dụng lại, với tôi, có một cửa hàng giúp việc di chuyển dễ dàng hơn bằng cách sử dụng các công cụ dev của Redux và không bị lẫn vào ứng dụng lớn ...

Ngoài ra, khái niệm về một cửa hàng đang bắt chước cơ sở dữ liệu cho chúng tôi, một nguồn sự thật mà bạn có thể thay đổi và bạn có thể truy cập nó trong bộ nhớ trình duyệt ...

Nếu toàn bộ ứng dụng được quản lý tốt, một cửa hàng có thể đủ để quản lý toàn bộ trạng thái ứng dụng ...