그래서 일주일 전에 React를 배우기 시작했고 필연적으로 상태 문제와 컴포넌트가 나머지 앱과 통신하는 방식에 대해 알게되었습니다. 나는 주위를 수색했고 Redux는 이달의 풍미 인 것 같다. 나는 모든 문서를 읽었고 실제로 꽤 혁신적인 아이디어라고 생각합니다. 그것에 대한 내 생각은 다음과 같습니다.
상태는 일반적으로 프로그래밍에서 매우 사악하고 버그의 큰 원인으로 동의됩니다. 앱 전체에 분산시키는 대신 Redux는 변경하기 위해 작업을 내 보내야하는 전역 상태 트리에 모든 것을 집중시키는 것이 어떨까요? 흥미 롭 네요. 모든 프로그램에는 상태가 필요하므로 하나의 불순한 공간에 고정하고 버그를 추적하기 쉽도록 내부에서만 수정하십시오. 그런 다음 개별 상태 조각을 React 구성 요소에 선언적으로 바인딩하고 자동으로 다시 그리면 모든 것이 아름답습니다.
그러나이 전체 디자인에 대해 두 가지 질문이 있습니다. 우선 상태 트리가 변경 불가능해야하는 이유는 무엇입니까? 시간 여행 디버깅, 핫 리로드에 신경 쓰지 않고 이미 내 앱에서 실행 취소 / 다시 실행을 구현했다고 가정 해 보겠습니다. 이 작업을 수행하는 것이 너무 번거로운 것 같습니다.
case COMPLETE_TODO:
return [
...state.slice(0, action.index),
Object.assign({}, state[action.index], {
completed: true
}),
...state.slice(action.index + 1)
];
대신 :
case COMPLETE_TODO:
state[action.index].completed = true;
말할 것도없이 내가 배우기 위해 온라인 화이트 보드를 만들고 있으며 모든 상태 변경은 명령 목록에 브러시 스트로크를 추가하는 것만 큼 간단 할 수 있습니다. 잠시 후 (수백 번의 브러시 스트로크)이 전체 어레이를 복제하면 비용과 시간이 많이 소요될 수 있습니다.
액션을 통해 변경되는 UI와는 독립적 인 전역 상태 트리는 괜찮지 만 실제로 변경 불가능해야합니까? 이와 같은 간단한 구현 (매우 대략적인 초안. 1 분 만에 작성)이 잘못된 것은 무엇입니까?
var store = { items: [] };
export function getState() {
return store;
}
export function addTodo(text) {
store.items.push({ "text": text, "completed", false});
}
export function completeTodo(index) {
store.items[index].completed = true;
}
방출 된 작업을 통해 변경된 전역 상태 트리이지만 매우 간단하고 효율적입니다.
immutablejs사용 하십시오return state.setIn([action.index, 'completed'], true);.