ReactJS 로컬 대 글로벌 상태 및 나중에 redux 구현

Question

그래서 우리는 프로젝트에 약 두 달입니다. 코드 작성자를 관리하고 코드를 직접 작성하지 않은 것은 이번이 처음입니다. 나는 지난주에 그들의 코드를 읽었습니다. 간단한 React 앱으로 생각했던 것이 스파게티 혼란으로 바뀌었다.

저는 이해합니다 : redux는 전역 상태를 관리하는 데 도움이됩니다. 그러나 모든 버튼이 글로벌 "행동"에 매핑되어야한다는 것을 의미합니까? 이것은 전체 애플 리케이션 전체에 흩어져 개체의 전체 엉망을 만드는 것 같았다. 로컬 상태가 응용 프로그램의 90 %에 사용될 수있을 때 모든 것을 전역 상태로 사용하는 이유는 무엇입니까?

let subitems = SidebarItems[state.type].sub_items; 
Store.dispatch(SidebarSubItemHandler(item.action, subitems[0], null)); 

if(item.sub_items[subitems[0]].param) { 
    browserHistory.push(`${item.sub_items[subitems[0]].path}/${item.sub_items[subitems[0]].param}`); 
} else { 
    browserHistory.push(item.sub_items[subitems[0]].path); 
} 

subItembuttons = Object.keys(this.props.subitems.sub_items).map(subitem => { 
    let subItem = this.props.subitems.sub_items[subitem]; 
    return <li className={this.props.activeSubItem.action == subItem.action ? "bottom-bar-item active" : "bottom-bar-item"} 
       onClick={e => this.props.onClickSubItem(e, subItem)} 
       key={subItem.action} style={this.props.subitems.inlineStyles.mobileSubItemLI}> 
     <a href="">{subItem.item}</a> 
    </li>; 
}); 

응용 프로그램이 "액션"객체를 매핑 이와 같은 개체의 모든 종류의 산재되어이 나에게 가슴 앓이를 제공 코드의 일종이다. 따라서 현재 전체 프로젝트를 폐기하고 처음부터 재시작하겠다는 결정을 내리고 있습니다. 로컬 상태를 사용하여 가능한 한 많이하려고합시다. 시간이 흐르면 ​​무언가를 위해 글로벌 상태가 필요합니다. 앱의 모든 단일 액션이 아니라 무언가를 위해서만 구현하십시오. 이게 말이 돼?

그래서 내 질문에 짐작할 수 있습니다. 우리가 지역의 주 및 단지 기본적인 React를 사용하여 응용 프로그램을 개발한다면 항목 단위로 redux를 구현할 수있는 되돌릴 수없는 문제가 발생하게됩니까? http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state에 관련 돌아 오는 질문 항목에서 인용

Answer 1

: 지역 구성 요소의 상태를 사용

는 괜찮습니다. 개발자로서 응용 프로그램을 구성하는 상태의 종류와 각 상태를 유지해야하는 위치를 결정하는 것은 사용자의 임무입니다. 자신에게 적합한 균형을 찾아서 함께 가십시오. 어떤 종류의 데이터가 돌아 오는에 투입해야한다 determing에 대한 엄지 손가락의

몇 가지 일반적인 규칙 :

• 이 데이터에 대한 응용 프로그램 관리의 다른 부분을합니까?
• 원본 데이터를 기반으로 추가 파생 데이터를 생성 할 수 있어야합니까?
• 여러 구성 요소를 구동하는 데 동일한 데이터가 사용됩니까? 이 상태를 주어진 시점 (즉, 타임 트래블 디버깅)으로 복원 할 수 있다는 것에 가치가 있습니까?
• 데이터를 캐시하고 싶습니까? 즉, 데이터를 다시 요청하는 대신 상태가 이미있는 경우 사용하십시오.
특정 질문 당

: 당신은 매우 일관되게 "컨테이너 구성 요소"패턴을 사용하는 경우, 그것은 선 아래로 돌아 오는 연결된 컨테이너에 대한 그 "일반 반작용"용기를 교환하는 비교적 간단해야한다. "컨테이너/프리젠 테이션 구성 요소"패턴에 대한 기사는 https://github.com/markerikson/react-redux-links/blob/master/react-component-patterns.md#component-categories을 참조하십시오.

두 개의 다른 생각. 첫째, 최근에 나는 why you might want to use Redux in a React application을 다루는 기사를 공동 저술했습니다.

둘째 : 예, 그 코드는 다소 추한 것 같습니다. 나는 코드베이스의 다른 부분에서 적어도 3 개의 서로 다른 코드 단편이 필요하기를 바라고 있지만 단편은 읽기가 어렵습니다. "sub_items"및 "subitems"를 반복적으로 사용하면 약간의 붉은 깃발처럼 보이기 쉽습니다.

또한 좋은 Redux 기법을 따르는 것처럼 보이지 않습니다. 예를 들어, 관용적 인 Redux 코드는 저장소를 직접 참조하지 않습니다. 대신 dispatch 및 getState에 대한 참조는 미들웨어를 통해 사용할 수 있으므로 redux-thunk 및 redux-saga을 통해 작업 작성자에서 사용할 수 있습니다. 연결된 구성 요소는 dispatch에 액세스 할 수도 있습니다.

전반적으로 : 원하는만큼 Redux를 사용하고 로컬 구성 요소 상태를 원하는만큼 많이 사용할 수 있습니다. 하지만 더 큰 문제는 팀이 실제로 Redux를 얼마나 잘 이해하고 있으며, Redux를 어떻게 사용하고 있는지를 잘 이해하고있는 것입니다.