Trong chương về Thiết kế Hình dạng Trạng thái , các tài liệu đề xuất giữ trạng thái của bạn trong một đối tượng được khóa bằng ID:
Giữ mọi thực thể trong một đối tượng được lưu trữ với ID làm khóa và sử dụng ID để tham chiếu nó từ các thực thể hoặc danh sách khác.
Họ tiếp tục trạng thái
Hãy coi trạng thái của ứng dụng như một cơ sở dữ liệu.
Tôi đang làm việc trên hình dạng trạng thái cho danh sách các bộ lọc, một số bộ lọc sẽ mở (chúng được hiển thị trong cửa sổ bật lên) hoặc có các tùy chọn đã chọn. Khi tôi đọc "Hãy nghĩ về trạng thái của ứng dụng như một cơ sở dữ liệu", tôi đã nghĩ về việc nghĩ chúng như một phản hồi JSON vì nó sẽ được trả về từ một API (chính nó được cơ sở dữ liệu hỗ trợ).
Vì vậy, tôi đã nghĩ về nó như là
[{
id: '1',
name: 'View',
open: false,
options: ['10', '11', '12', '13'],
selectedOption: ['10'],
parent: null,
},
{
id: '10',
name: 'Time & Fees',
open: false,
options: ['20', '21', '22', '23', '24'],
selectedOption: null,
parent: '1',
}]Tuy nhiên, tài liệu đề xuất một định dạng giống như
{
1: {
name: 'View',
open: false,
options: ['10', '11', '12', '13'],
selectedOption: ['10'],
parent: null,
},
10: {
name: 'Time & Fees',
open: false,
options: ['20', '21', '22', '23', '24'],
selectedOption: null,
parent: '1',
}
}Về lý thuyết, điều đó không thành vấn đề miễn là dữ liệu có thể tuần tự hóa (dưới tiêu đề "Trạng thái") .
Vì vậy, tôi đã hài lòng với phương pháp tiếp cận mảng đối tượng, cho đến khi tôi viết trình thu gọn của mình.
Với cách tiếp cận đối tượng-keyed-by-id (và sử dụng tự do cú pháp lây lan), OPEN_FILTERmột phần của trình giảm thiểu trở thành
switch (action.type) {
case OPEN_FILTER: {
return { ...state, { ...state[action.id], open: true } }
}Trong khi với cách tiếp cận mảng đối tượng, thì càng dài dòng hơn (và phụ thuộc vào hàm trợ giúp)
switch (action.type) {
case OPEN_FILTER: {
// relies on getFilterById helper function
const filter = getFilterById(state, action.id);
const index = state.indexOf(filter);
return state
.slice(0, index)
.concat([{ ...filter, open: true }])
.concat(state.slice(index + 1));
}
...Vì vậy, câu hỏi của tôi gấp ba lần:
1) Sự đơn giản của bộ giảm thiểu có phải là động lực để sử dụng phương pháp tiếp cận đối tượng-keyed-by-id không? Có những ưu điểm nào khác đối với hình dạng trạng thái đó không?
và
2) Có vẻ như cách tiếp cận đối tượng-keyed-by-id khiến việc xử lý JSON tiêu chuẩn vào / ra cho một API khó hơn. (Đó là lý do tại sao tôi đã sử dụng mảng đối tượng ngay từ đầu.) Vì vậy, nếu bạn đi với cách tiếp cận đó, bạn có chỉ sử dụng một hàm để chuyển đổi nó qua lại giữa định dạng JSON và định dạng hình dạng trạng thái không? Điều đó có vẻ khó hiểu. (Mặc dù nếu bạn ủng hộ cách tiếp cận đó, thì có phải một phần lý do của bạn rằng nó ít rắc rối hơn trình giảm bớt mảng đối tượng ở trên?)
và
3) Tôi biết Dan Abramov đã thiết kế redux về mặt lý thuyết là bất khả tri về cấu trúc dữ liệu-trạng thái (như được gợi ý bởi "Theo quy ước, trạng thái cấp cao nhất là một đối tượng hoặc một số tập hợp khóa-giá trị khác như Bản đồ, nhưng về mặt kỹ thuật, nó có thể là bất kỳ gõ " nhấn mạnh của tôi). Nhưng với những điều trên, liệu có phải chỉ là "được khuyến nghị" giữ nó là một đối tượng được khóa bởi ID, hay có những điểm khó lường khác mà tôi sẽ gặp phải bằng cách sử dụng một mảng các đối tượng khiến nó trở nên như vậy mà tôi chỉ nên hủy bỏ nó. lập kế hoạch và cố gắng gắn bó với một đối tượng được khóa bởi ID?