상태 모양 디자인 장에서 문서는 ID로 키가 지정된 객체에 상태를 유지하도록 제안합니다.
ID와 함께 저장된 개체의 모든 항목을 키로 유지하고 ID를 사용하여 다른 항목이나 목록에서 참조합니다.
그들은 상태로 이동
앱의 상태를 데이터베이스로 생각하십시오.
필터 목록에 대한 상태 모양을 작업 중이며 일부는 열리거나 (팝업에 표시됨) 옵션을 선택했습니다. "Think of the app 's state as a database"를 읽었을 때 API (데이터베이스에서 자체적으로 지원)에서 반환되는 JSON 응답으로 생각했습니다.
그래서 나는 그것을 생각했습니다
[{
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',
}]
그러나 문서는 다음과 같은 형식을 제안합니다.
{
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',
}
}
이론적으로 데이터를 직렬화 할 수있는 한 ( "State"제목 아래) 중요하지 않습니다 .
그래서 저는 감속기를 작성할 때까지 행복하게 객체 배열 접근 방식을 사용했습니다.
object-keyed-by-id 접근 방식 (및 확산 구문의 자유로운 사용)을 사용 OPEN_FILTER하면 감속기 의 일부가
switch (action.type) {
case OPEN_FILTER: {
return { ...state, { ...state[action.id], open: true } }
}
객체 배열 접근 방식의 경우 더 장황합니다 (및 도우미 기능에 의존).
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));
}
...
그래서 내 질문은 세 가지입니다.
1) 감속기의 단순성이 object-keyed-by-id 접근 방식을 사용하는 동기입니까? 그 상태 모양에 다른 이점이 있습니까?
과
2) id에 의한 object-keyed 접근 방식은 API에 대한 표준 JSON 입출력을 처리하는 것을 더 어렵게하는 것 같습니다. (이것이 제가 처음에 객체 배열을 사용하는 이유입니다.) 따라서 이러한 접근 방식을 사용한다면 함수를 사용하여 JSON 형식과 상태 모양 형식간에 앞뒤로 변환합니까? 투박해 보입니다. (당신이 그 접근 방식을 옹호한다면, 위의 객체 배열 감속기보다 덜 투박하다는 추론의 일부입니까?)
과
3) Dan Abramov가 이론적으로 상태 데이터 구조에 구애받지 않도록 redux를 설계 한 것을 알고 있습니다 ( "관례 상 최상위 상태는 객체 또는지도와 같은 다른 키-값 컬렉션이지만 기술적으로는 type , " 내 강조). 그러나 위의 경우 ID로 키가 지정된 개체를 유지하는 것이 "권장"입니까, 아니면 중단해야하는 개체 배열을 사용하여 실행할 다른 예상치 못한 문제점이 있습니까? ID로 키가 지정된 개체를 계획하고 유지하려고합니까?