Cách tích hợp Redux với tập dữ liệu rất lớn và IndexedDB

Question

Tôi có một ứng dụng sử dụng API đồng bộ hóa để lấy dữ liệu và yêu cầu lưu trữ tất cả dữ liệu cục bộ. Tập dữ liệu chính nó là rất lớn, và tôi miễn cưỡng lưu trữ nó trong bộ nhớ, vì nó có thể chứa hàng ngàn bản ghi. Vì tôi không nghĩ rằng cấu trúc dữ liệu thực sự có liên quan, hãy giả sử tôi đang xây dựng một ứng dụng email cần truy cập ngoại tuyến và tôi muốn cơ chế lưu trữ của mình là IndexedDB (không đồng bộ).

Tôi biết rằng giải pháp đơn giản là không có cấu trúc dữ liệu như một phần của đối tượng tiểu bang của tôi và chỉ điền vào trạng thái với dữ liệu bắt buộc (ví dụ: - lưu trữ nội dung email về trạng thái khi hành động EMAIL_OPEN được kích hoạt). Điều này khá đơn giản, đặc biệt với redux-thunk.

Tuy nhiên, điều này sẽ có nghĩa là tôi cần phải thỏa hiệp 2 điều:

1. Các dữ liệu người dùng là một phần không còn của "trạng thái ứng dụng", mặc dù trong thực tế nó được. Vì hành vi đồng bộ là phức tạp và việc xóa nó khỏi máy trạng thái ứng dụng sẽ làm tổn thương sự sang trọng của các khái niệm redux (cách tôi hiểu chúng)
2. Tôi thực sự thích cấu trúc redux và muốn tất cả logic của tôi đi qua nó , không chỉ trạng thái xem.

Có cách nào hay nhất về cách sử dụng Redux với thuộc tính trạng thái không có trong bộ nhớ không? Điều tôi thấy khó khăn nhất là dùng redux dựa trên các API đồng bộ, và vì vậy tôi không thể thay thế đối tượng trạng thái của mình bằng đối tượng trạng thái không đồng bộ (trừ khi tôi loại bỏ hoàn toàn redux và thay thế nó bằng trình cài đặt và kết nối không đồng bộ của riêng tôi).

Tôi không thể tìm thấy câu trả lời bằng Google, nhưng nếu đã có tài nguyên tốt về chủ đề tôi cũng muốn được chỉ ra.

UPDATE: Câu hỏi đã được trả lời nhưng muốn để cho một explantation tốt hơn vào cách tôi thực hiện nó, trong trường hợp ai đó chạy vào nó:

Ý tưởng chính là để duy trì danh sách thay đổi của cả client và server sử dụng đơn giản Redux bộ giảm tốc và sử dụng trình kết nối để nghe các danh sách thay đổi này để cập nhật IDB và cũng để cập nhật máy chủ với các thay đổi của khách hàng:

1. Khi khách hàng thực hiện thay đổi, hãy sử dụng bộ giảm tốc để cập nhật danh sách thay đổi của khách hàng.
2. Khi máy chủ gửi cập nhật, hãy sử dụng bộ giảm tốc để cập nhật danh sách thay đổi máy chủ.
3. Trình kết nối nghe lưu trữ và cập nhật thay đổi trạng thái IDB. Cũng duy trì danh sách nội bộ của các mục đã được sửa đổi.
4. Khi cập nhật máy chủ, hãy sử dụng danh sách các mục đã sửa đổi để kéo delta từ IDB và gửi tới máy chủ.
5. Khi truy cập vào các dữ liệu, sử dụng hoạt động bình thường để kéo từ IDB (ví dụ sử dụng Redux-thunk)

Thông báo trước với phương pháp này là kể từ khi nhà nước thực được lưu trữ trong IDB, vì vậy chúng tôi mất một số giá trị của việc có một đối tượng trạng thái (và cũng khó khăn hơn để tua lại/tua nhanh)

Answer 1

Tôi nghĩ linh cảm đầu tiên của bạn là chính xác. Nếu (!) Bạn không thể lưu trữ mọi thứ trong cửa hàng, bạn phải lưu trữ ít hơn trong cửa hàng.Nhưng tôi tin rằng tôi có thể làm cho giải pháp đó nghe tốt hơn nhiều:

Chỉ mụcDB chỉ trở thành điểm cuối khác, giống như bất kỳ API máy chủ nào bạn sử dụng. Khi bạn lấy dữ liệu từ máy chủ, bạn chuyển tiếp nó đến IndexedDB, từ đó lưu trữ của bạn sau đó được điền. Các cửa hàng được chỉ là những gì nó cần và lưu trữ nó miễn là nó không nhận được quá lớn hoặc cũ.

Nó thực sự không khác với Facebook nói về việc tiêu thụ API của họ. Không bao giờ có tất cả dữ liệu cho người dùng trong cửa hàng. Tài liệu tham khảo được triển khai bằng ID và các tham chiếu này được tải khi được yêu cầu.

Bạn có thể giữ tất cả logic của mình trong quá trình chuyển đổi. Chỉ cần tạo các hành động như thường lệ cho hành động của người dùng và thay đổi dữ liệu, lấy dữ liệu bạn cần và xử lý nó. Giao diện vẫn hoàn toàn được xác định bởi dữ liệu người dùng bởi vì bạn luôn có thông tin trong cửa hàng cần thiết để NHẬN phần còn lại của nó khi cần. Nó chỉ hơi ngưng tụ, tôi. e. bạn chỉ lưu tổng số tin nhắn hoặc ID của hộp thư cho đến khi người dùng điều hướng đến nó.