React-Redux: 모든 컴포넌트 상태를 Redux Store에 저장해야 합니까?

React-Redux: 모든 컴포넌트 상태를 Redux Store에 저장해야 합니까?

간단한 전환이 있다고 가정합니다.

버튼을 클릭하면 Color 컴포넌트가 빨간색과 파란색으로 바뀝니다.

나는 이런 일을 함으로써 이 결과를 얻을 수 있을지도 모른다.

index.displaces를 표시합니다.

Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red

container.container.displaces

connect(mapStateToProps)(indexPage)

action_syslog.syslogs

function changeColor(){
 return {type: 'CHANGE_COLOR'}
}

리듀서.리듀서

switch(){
case 'CHANGE_COLOR':
return {color: true}

jQuery, 수업, css로 5초 만에 달성할 수 있는 엄청난 양의 코드입니다.

그래서 제가 정말 묻고 싶은 건, 제가 여기서 뭘 잘못하고 있는 걸까요?

Redux는 주로 "어플리케이션 상태"를 대상으로 합니다.즉, 애플리케이션 로직과 관련된 모든 것을 말합니다.그 위에 빌드된 뷰는 해당 상태를 반영하지만 모든 작업에 해당 상태 컨테이너를 단독으로 사용할 필요는 없습니다.

을 사용하다이 상태가 어플리케이션의 나머지 부분에 중요합니까?그 상태에 따라 어플리케이션의 다른 부분이 다르게 동작합니까?많은 사소한 경우, 그렇지 않을 것이다.드롭다운 메뉴를 선택합니다.열림이나 닫힘이 앱의 다른 부분에는 영향을 주지 않을 것입니다. 는 메리트를 수 .확실히 유효한 옵션이지만, 메리트를 얻을 수 있는 것은 아닙니다. 하는 게 요.this.state오늘은 여기까지.

이 예에서 버튼의 색상이 어플리케이션의 다른 부분에 영향을 미칩니까?어플리케이션의 주요 부분에 대한 글로벌 온/오프 전환이 있을 경우 스토어 내에 있어야 합니다.그러나 버튼을 클릭할 때 버튼 색상을 전환하는 경우 색상 상태를 로컬로 정의된 상태로 둘 수 있습니다.버튼을 클릭하는 동작은 액션 디스패치가 필요한 다른 효과를 가져올 수 있지만, 이는 어떤 색상으로 해야 하는지에 대한 단순한 질문과는 별개입니다.

일반적으로 응용 프로그램 상태를 가능한 작게 유지하십시오.모든 걸 다 집어넣을 필요는 없어꼭 해야 할 때 하세요. 그렇지 않으면 거기에 뭔가를 보관하는 것이 말이 됩니다.또는 Dev Tools를 사용할 때 더 쉽게 작업할 수 있습니다.하지만 그것의 중요성을 너무 과중하게 하지 마세요.

FAQ: State FAQ: 조직상상 。
레독스 공식 문서의 이 부분은 당신의 질문에 잘 대답했습니다.

로컬 컴포넌트 상태를 사용해도 괜찮습니다.개발자로서 애플리케이션을 구성하는 상태 및 각 상태의 위치를 결정하는 것은 사용자의 일입니다.자신에게 맞는 밸런스를 찾아서 그것을 따르세요.

Redux에 넣을 데이터의 종류를 결정하기 위한 일반적인 경험적 규칙은 다음과 같은 규칙이 있습니다.

• 어플리케이션의 다른 부분은 이 데이터에 관심이 있습니까?
• 이 원본 데이터를 기반으로 추가 파생 데이터를 생성할 수 있어야 합니까?
• 동일한 데이터를 사용하여 여러 컴포넌트를 구동하고 있습니까?
• 이 상태를 특정 시점으로 복원할 수 있는 데 가치가 있습니까(즉, 시간 이동 디버깅).
• 데이터를 캐시하시겠습니까(즉, 데이터를 다시 요청하지 않고 이미 있는 경우 사용)?

@AR7에 의해 제공되는 훌륭한 링크를 강조하기 위해, 그리고 그 링크가 조금 전에 이동했기 때문에:

React는 앱 전체에 영향을 주지 않고 복잡한 방식으로 변환되지 않는 사용 후 삭제 상태를 나타냅니다.예를 들어 일부 UI 요소의 전환, 양식 입력 상태 등이 있습니다.세계적으로 중요하거나 복잡한 방식으로 변환되는 상태에는 Redx를 사용합니다.예를 들어 캐시된 사용자 또는 포스트 초안입니다.

때로는 Redux 상태에서 React 상태로 전환하거나(Redx에 무언가를 저장하는 것이 어색해지면) 그 반대로 전환하거나(더 많은 구성 요소가 로컬 상태에 액세스해야 할 경우) 그 반대로 전환해야 합니다.

경험의 법칙은: 덜 어색한 것은 무엇이든지 해라.

Dan Abramov: https://github.com/reactjs/redux/issues/1287#issuecomment-175351978

이는 개발자들이 지나치게 강화된 상태 설계인 Redux의 문제이며, 이는 항상 상당히 단순할 수 있는 애플리케이션을 복잡한 구조로 변화시킵니다.

Redux는 구현하기 전에 잘 계획하고 설계해야 하는 리액션 아키텍처입니다.

https://kentcdodds.com/blog/application-state-management-with-react/ "redux가 성공한 이유 중 하나는 react-redux가 Prop-Drilling 문제를 해결했기 때문입니다.마법의 연결 기능에 컴포넌트를 전달하기만 하면 트리의 여러 부분에 걸쳐 데이터를 공유할 수 있다는 사실은 놀라웠습니다.리듀서/액션 크리에이터 등의 사용도 훌륭하지만, 리듀스의 보급은 개발자의 Prop-Drilling 과제를 해결했기 때문이라고 생각합니다.

이것이 바로 제가 지금까지 한 프로젝트에서만 redux를 사용한 이유입니다.나는 개발자들이 그들의 모든 상태를 축소하는 것을 항상 본다.글로벌 애플리케이션 상태뿐만 아니라 로컬 상태도 마찬가지입니다.이로 인해 많은 문제가 발생합니다.그 중 중요한 것은 상태 상호작용을 유지할 때 리듀서, 액션 작성자/유형 및 디스패치 콜과의 상호작용이 수반된다는 것입니다.결과적으로 어떤 일이 일어나고 있는지, 그리고 그것이 코드베이스의 나머지 부분에 어떤 영향을 미치는지 알기 위해 많은 파일을 열어 머릿속에서 코드를 추적해야 합니다.“”

간단히 말하면: 안 돼!

React는 Redx용으로 생성되지 않았으며 Redx는 React용으로 생성되지 않았습니다.

공식 웹사이트(https://redux.js.org/faq/general):

이것을 수정하고 싶다: 바닐라 리액트에 문제가 생길 때까지 Redux를 사용하지 마라.

따라서 Redux 없이 작업을 수행할 수 있다면 사용하지 않는 것이 좋습니다.그리고 제 과거 경험으로 볼 때, 다음과 같은 여러 가지 이유로 매우 건강한 권장 사항입니다.

1. 어플리케이션과 함께 확장되는 많은 보일러 플레이트(이것은 Redux 툴킷에도 해당되며, 여전히 많은 추가 코드가 있지만 일반 Redux만큼 많지 않습니다).

2. 시제품 제작이 빠른 속도로 작동되는지 확인할 수 없습니다.

3. 배송 속도가 느려지기 때문에 항상 빠른 방법으로 배송해야 하는 경우 Redux를 위한 시간이 없습니다.

4. 구성 요소는 다른 데이터 집합과 함께 재사용할 수 없습니다.앱 전체에 100개의 다른 유형의 엔티티를 검색하기 위한 100개의 타이프라헤드가 있다고 생각해 보세요.모든 도면요소를 동일한 데이터 구조로 조정해야 하며 사용자는 해당 상태에 대한 쓰기 순서를 제어할 수 없습니다.인스턴스화된 컴포넌트는 언제 어디서나 이 상태로 디스패치할 수 있습니다.

5. 글로벌 액세스는 통상, 애플리케이션을 예측할 수 없는 상태가 될 가능성이 있기 때문에, 프로그래밍에서는 좋지 않습니다.인스턴스화된 모든 구성 요소는 언제든지 무엇이든 변경할 수 있습니다.그래서 당신이 꿈에도 생각하지 못했던 상태에 빠질 가능성이 높습니다.그리고 이 가능성은 애플리케이션과 함께 높아집니다. 왜냐하면 글로벌 액세스가 증가하고 있기 때문입니다.물론 Redx는 애플리케이션을 예측할 수 없는 상태로 만든 경로를 추적하는 데 도움이 되는 놀라운 개발 툴과 아키텍처를 갖추고 있습니다.하지만 그걸 피하면서 왜 추적에 시간을 쓰죠?

6. A, B, C 및 D가 같은 글로벌스테이트를 공유하고 있기 때문에 플레이스A의 변경으로 인해 B, C, D의 어떤 것이 파괴될 가능성이 있기 때문에 글로벌접근은 새로운 기능 개발 및 버그 수정에는 좋지 않습니다.따라서 수정/개발을 할 때는 어디서든, 어디서든, 어디서든 회귀를 해야 합니다. 이 역시 시간이 많이 걸리고 애플리케이션이 커질수록 상황이 더 악화됩니다.Bullet prof 자동 회귀 테스트를 실시하지 않으면 프로덕션에서의 신속한 버그 수정은 악몽이 될 것입니다.

7. Redux를 사용하면 종속성 주입을 사용하지 않기 때문에 Redx를 사용하는 구성 요소에 대한 단위 테스트가 훨씬 더 어려워집니다.모든 개발자는 의존성 주입이 유닛 테스트의 가장 좋은 친구 중 하나라는 것을 알고 있습니다.어쨌든 Redux 부품을 마법적으로 조롱할 수 있는 서드파티 라이브러리를 찾아야 합니다.그러나 유닛 테스트의 수가 증가함에 따라 문제가 발생합니다.이는 주로 글로벌 액세스와 사용자가 제어할 수 없는 마법의 조롱 때문입니다.모든 개발자는 글로벌 액세스가 유닛 테스트와 확장 가능한 코드의 가장 큰 적 중 하나라는 것을 알고 있습니다.따라서 어플리케이션이 커짐에 따라 유닛 테스트는 악몽이 될 것입니다.

8. 애플리케이션이 성장하기 시작하면서 주정부도 계속 성장하며, 특히 제대로 계획되지 않았다면 따라가기가 매우 어려울 것입니다.

9. 애플리케이션의 확장에 수반해, 퍼포먼스(UI 레벨)의 문제가 발생합니다.

제 경험에 비추어 볼 때, 저는 그렇게 하지 말고, Redx가 해결할 수 있는 문제와 vanilla React가 해결할 수 없는 문제가 있는지 확인하고, 그 후에야 사용할 수 있습니다.

저는 인터넷에서 Redx를 큰 어플리케이션으로 사용해야 한다는 글을 자주 읽습니다.그리고 나는 위에서 언급한 이유로 이 진술에 동의하지 않는다.글로벌 상태 및 글로벌 액세스가 길어질수록 개발, 버그 수정, 테스트 시간도 증가할 가능성이 높아집니다. 왜냐하면 "글로벌"은 많은 이유로 프로그래밍에서 일반적으로 나쁜 단어이기 때문입니다.따라서 "글로벌" 제품을 사용할 때는 주의해야 합니다.물론 Redx는 특별한 종류의 글로벌 액세스로 업무와 시간 여행을 제어하고 있습니다.하지만 여전히 그것은 현명하게 사용되어야 한다.글로벌 액세스는 일반적으로 어떻게, 언제, 어떤 목적으로 사용되는지에 따라 매우 유용하거나 매우 해로울 수 있습니다.

Redux는 복잡한 애플리케이션에도 적합하며 복잡한 부품이 있는 한 소규모 애플리케이션에도 적합합니다.단, 복잡도가 낮으면 대규모 애플리케이션은 절대 아닙니다.예를 들어 보겠습니다.

100장 이상의 "페이지"를 가진 대규모 SPA를 사용할 수 있으며, 고객은 어제 배송을 희망하고 있습니다.각 페이지는 그다지 복잡하지 않은 다른 유형의 엔티티에 대한 CRUD 인터페이스를 나타냅니다.엔티티는 2개의 다른 페이지에서 사용되지 않습니다.이 경우 모든 페이지가 다른 페이지와 무관한데 왜 곳곳에 Redx를 추가합니까?각 페이지 레벨에서 로컬 상태를 유지하고 캡슐화하며 추상 비동기 함수로 기본 소품을 통해 데이터 서비스를 주입할 수 있습니다.이것이 끝입니다.추상적인 방법으로 데이터 서비스를 주입하고 A페이지를 터치하여 B, C, D페이지에 있는 무언가를 파손할 염려가 없기 때문에 코드 수가 적어지고, 전송 속도가 빨라지며, 테스트 속도가 빨라집니다.

한편, 「페이지」라고 하는 작은 애플리케이션도 사용할 수 있습니다.그러나 이 페이지에는 30개의 서로 다른 내부 컴포넌트가 포함되어 있습니다.각 컴포넌트는 사용자가 조작할 수 있으며, 각 컴포넌트는 어디에서나 많은 클릭, 더블 클릭, 오른쪽 클릭, 드래그 앤 드롭, 크기 조정 및 입력이 가능합니다.또한 컴포넌트 상태는 다른 컴포넌트 상태에 따라 달라집니다.일부 구성요소는 상태 등에 따라 다른 구성요소와 교환됩니다.확실히 여기서 Redux가 더 나은 선택입니다.

또는 어떤 사람들은 단 하나의 소스 진실이 있기 때문에 Redux로 모든 것을 해야 한다고 말합니다.그러나 서버 데이터의 경우 엔드포인트가 유일한 정보원이 되지 않습니까?이미 일원화된 정보 소스(실제 BE 엔드포인트)가 1개 있는데 왜 서버 데이터의 복사본을 UI에서 일원화해야 합니까?엔드포인트에 대한 쿼리는 UI의 모든 위치에서 언제든지 변경할 수 있는 글로벌 복사본을 쿼리하는 것보다 훨씬 더 번거롭습니다.캐싱에 대해 말하는 사람이 있다면, 우선 캐싱이 필요한지 여부를 알아야 하며, 두 번째 Redux는 캐싱용으로 개발되지 않았습니다.Respect Query와 같은 캐싱을 위한 전용 라이브러리가 존재하며, 이러한 목적을 위해 훨씬 더 우아하고 유연합니다.UI 상태(예: isModalVisible)에 대해서는, 각 「페이지」에는, 독자적인 캡슐화된 단일의 진실 소스가 필요합니다.위에서 설명한 모든 이유로 로컬로 되어 있는 것을 글로벌하게 액세스 하는 것은 또 하나의 잘못된 관행이기 때문입니다.

컴포넌트가 데이터 소스를 모르기 때문에 서버 데이터를 Redx에 넣어야 한다는 이야기를 자주 들었습니다.물론입니다만, 요청을 하는 소품을 통해 비동기 함수를 삽입해도 구성 요소는 여전히 데이터 소스를 인식하지 못합니다.이는 추상화를 사용하고 있으며 많은 다른 도우미를 설치하지 않고도 쉽게 테스트할 수 있습니다.

일부에서는 프롭 드릴링을 피하기 위해 Redx를 사용하지만, 일반적으로 "페이지"가 복잡하지 않다면 구성 요소의 깊은 트리가 생성되지 않아야 합니다.대부분의 컴포넌트는 레이아웃 컴포넌트일 가능성이 높기 때문에 children 속성을 사용하여 드릴로 뚫어야 하는 중간 컴포넌트를 추출하여 아래 데이터를 전달할 수 있습니다.

결론적으로 공식 웹사이트에 나와 있는 것과 같은 말을 합니다.

"바닐라 리액트에 문제가 생길 때까지 레덕스를 사용하지 마세요"

Redx는 서버 데이터 저장용으로 개발되지 않았습니다.이 작업은 vanilla React를 사용하여 수행할 수 있습니다.Redux는 UI 상태를 위해 개발되지 않았습니다. Vanilla React를 사용하여 이를 수행할 수 있습니다.Redux는 캐싱용으로 개발된 것이 아닙니다.이것은 다른 이야기이며, 통상 서버측에서 실시해야 합니다만, 서버상에서 어떠한 이유로 가능성이 없는 경우는, React Query와 같이 FE상에서 캐싱하기 위한 전용 툴입니다.Redx는 대규모 애플리케이션용으로 개발되지 않았습니다.좀 똑똑하고 정리된 사용자라면 vanilla React에서 이 작업을 수행할 수 있습니다.

Redx는 복잡한 응용 프로그램 또는 복잡한 부품을 포함하는 응용 프로그램을 위해 복잡한 문제를 해결하기 위해 개발되었으며, 이로 인해 vanilla React에서 큰 문제가 발생합니다.페이스북처럼 어플리케이션이 거대하고 복잡하며, 매일 수십억 개 이상의 요청이 있기 때문에 모든 것을 신속하게 수정해야 합니다.제가 여러 블로그에서 읽은 바로는, 그들은 Redux를 기반으로 아키텍처를 구축한 것이 아니라, 실제로 다른 솔루션이 없는 문제에 직면했을 때 이 아키텍처를 소개했습니다.이러한 "스트레스"가 높은 앱의 성능 문제(각 요구 및 열린 웹 소켓 수)를 방지하고 비교적 쉬운 수정을 제공하기 위해, 이 앱 위에 구축하지 않는 것을 수정하는 글로벌 액세스 메커니즘(여기서는 글로벌한 것이 영웅입니다)이 필요했습니다.또, 애플리케이션을 바람직하지 않은 상태로 하는 패스를 디버깅해 트레이스 할 수 있도록, 이 글로벌액세스가 예측 가능하고, 시간여행이 필요했습니다.

따라서 vanilla React에 문제가 없는 한 해결해야 할 복잡한 문제가 없는 한 Redux가 필요하지 않습니다.당신은 단지 조금 똑똑하고 체계적이어야 합니다.

리액트 주(州)를 경찰서로, 레독스 주를 스와트 팀으로 생각해 보세요.경찰서에서 처리하지 못할 때 SWAT팀에 연락하면 돼경찰이 할 일이 많다고 해서 SWAT 팀이 경찰 일을 하게 하는 것은 아니다(대형 앱).넌 SWAT 팀이 훈련받은 일을 하도록 내버려뒀어

네, 모든 컴포넌트 상태를 Redux에 저장하기 위해 노력할 가치가 있습니다.이 경우 시간 여행 디버깅 및 재생 가능한 버그 보고서와 같은 Redux의 많은 기능을 활용할 수 있습니다.그렇지 않으면 이러한 기능을 완전히 사용할 수 없게 될 수 있습니다.

구성 요소 상태 변경을 Redx에 저장하지 않으면 변경 내용이 Redx 변경 스택에서 완전히 손실되고 애플리케이션 UI가 스토어와 동기화되지 않습니다.이것이 전혀 중요하지 않다면 왜 Redux를 사용하는지 자문해 보십시오.이 기능이 없으면 응용 프로그램의 복잡성이 줄어듭니다.

퍼포먼스상의 이유로, 다음의 순서로 폴백 할 수 있습니다.this.setState()여러 가지 행동을 반복할 수 있는 어떤 것에 대해서도요예를 들어 사용자가 키를 입력할 때마다 입력 필드 상태를 Redux에 저장하면 성능이 저하될 수 있습니다.이를 트랜잭션처럼 처리함으로써 해결할 수 있습니다. 사용자 액션이 "커밋"되면 최종 상태를 Redux에 저장합니다.

원래 게시물에서는 Redux 방식이 "작성해야 할 코드가 너무 많다"고 언급하고 있습니다.예, 하지만 로컬 구성 요소 상태와 같은 일반적인 패턴에 추상화를 사용할 수 있습니다.

언급URL : https://stackoverflow.com/questions/35328056/react-redux-should-all-component-states-be-kept-in-redux-store