리뷰나라

Quora에서는 누군가가 말합니다 .

우선 Flux없이 React를 사용하여 앱을 작성할 수 있습니다.

또한이 시각적 다이어그램 은 두 가지에 대한 빠른보기를 보여주기 위해 만들었습니다. 전체 설명을 읽고 싶지 않은 사람들에게는 빠른 대답 일 것입니다.

그러나 여전히 더 알고 싶다면 계속 읽으십시오.

나는 순수한 React로 시작한 다음 Redux와 Flux를 배워야한다고 생각합니다. React에 대한 REAL 경험이 있으면 Redux가 도움이되는지 여부를 알 수 있습니다.

아마도 Redux가 앱에 대한 것이라고 생각하고 Redux가 실제로 경험하지 않는 문제를 해결하려고한다는 것을 알게 될 것입니다.

Redux로 직접 시작하면 오버 엔지니어링 된 코드, 유지 보수가 더 어려운 코드, 훨씬 더 많은 버그 및 Redux가없는 코드로 끝날 수 있습니다.

에서 돌아 오는 워드 프로세서 :

동기 부여
JavaScript 단일 페이지 응용 프로그램의 요구 사항이 점점 복잡해지면서 코드는 그 어느 때보 다 많은 상태를 관리해야합니다. 이 상태에는 서버 응답 및 캐시 된 데이터뿐만 아니라 아직 서버에 유지되지 않은 로컬로 작성된 데이터가 포함될 수 있습니다. 활성 경로, 선택된 탭, 스피너, 페이지 매김 컨트롤 등을 관리해야하므로 UI ​​상태도 점점 복잡해지고 있습니다.

끊임없이 변화하는이 상태를 관리하는 것은 어렵습니다. 모델이 다른 모델을 업데이트 할 수 있으면 뷰가 모델을 업데이트하여 다른 모델을 업데이트하면 다른 뷰가 업데이트 될 수 있습니다. 어떤 시점에서 더 이상 언제, 왜, 어떻게 상태에 대한 제어권을 잃어 앱에서 어떤 일이 발생하는지 이해하지 못합니다. 시스템이 불투명하고 결정적이지 않은 경우 버그를 재현하거나 새로운 기능을 추가하기가 어렵습니다.

이것이 나쁘지 않은 것처럼 프런트 엔드 제품 개발에서 새로운 요구 사항이 일반화되는 것을 고려하십시오. 개발자는 낙관적 업데이트, 서버 측 렌더링, 경로 전환을 수행하기 전에 데이터 페치 등을 처리해야합니다. 우리는 이전에 다룰 필요가 없었던 복잡성을 관리하려고 노력하고 있으며 필연적으로 다음과 같은 질문을합니다. 대답은 ‘아니오.

인간이 생각하기 어려운 두 가지 개념, 즉 돌연변이와 비동기 성이 혼합되어 있기 때문에 이러한 복잡성을 다루기가 어렵습니다. 나는 그들을 멘토스와 콜라라고 부릅니다. 둘 다 분리하면 좋을 수 있지만 함께 엉망이됩니다. React와 같은 라이브러리는 비동기 및 직접 DOM 조작을 모두 제거하여 뷰 계층에서이 문제를 해결하려고합니다. 그러나 데이터 상태 관리는 사용자의 몫입니다. Redux가 들어온 곳입니다.

Flux, CQRS 및 Event Sourcing의 발자취를 따라 Redux는 업데이트가 언제 어떻게 발생할 수 있는지에 대한 특정 제한을 부과하여 상태 돌연변이를 예측 가능하게 만듭니다. 이러한 제한은 Redux의 세 가지 원칙에 반영됩니다.

또한 Redux 문서에서 :

핵심 개념
Redux 자체는 매우 간단합니다.

앱의 상태가 평범한 객체라고 설명한다고 상상해보십시오. 예를 들어, 할 일 앱의 상태는 다음과 같습니다.

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

이 객체는 세터가 없다는 점을 제외하고는 “모델”과 같습니다. 이것은 코드의 다른 부분이 상태를 임의로 변경할 수 없으므로 재현하기 어려운 버그를 유발합니다.

상태에서 무언가를 변경하려면 작업을 전달해야합니다. 액션은 무슨 일이 일어 났는지 설명하는 평범한 자바 스크립트 객체입니다. 다음은 몇 가지 동작 예입니다.

{ type: 'ADD_TODO', text: 'Go to swimming pool' }
{ type: 'TOGGLE_TODO', index: 1 }
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

모든 변경 사항을 동작으로 설명하면 앱에서 진행되는 작업을 명확하게 이해할 수 있습니다. 무언가가 바뀌면 왜 바뀌 었는지 알 수 있습니다. 행동은 일어난 일의 빵 부스러기와 같습니다. 마지막으로 상태와 동작을 연결하기 위해 감속기라는 함수를 작성합니다. 다시 말하지만, 마법은 없습니다. 상태와 동작을 인수로 사용하여 앱의 다음 상태를 반환하는 함수일뿐입니다. 큰 앱에는 이러한 함수를 작성하기가 어려우므로 상태의 일부를 관리하는 작은 함수를 작성합니다.

function visibilityFilter(state = 'SHOW_ALL', action) {
  if (action.type === 'SET_VISIBILITY_FILTER') {
    return action.filter;
  } else {
    return state;
  }
}

function todos(state = [], action) {
  switch (action.type) {
  case 'ADD_TODO':
    return state.concat([{ text: action.text, completed: false }]);
  case 'TOGGLE_TODO':
    return state.map((todo, index) =>
      action.index === index ?
        { text: todo.text, completed: !todo.completed } :
        todo
   )
  default:
    return state;
  }
}

그리고 해당 상태 키에 대해 두 개의 감속기를 호출하여 앱의 전체 상태를 관리하는 다른 감속기를 작성합니다.

function todoApp(state = {}, action) {
  return {
    todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

이것은 기본적으로 Redux의 전체 아이디어입니다. Redux API는 사용하지 않았습니다. 이 패턴을 용이하게하는 몇 가지 유틸리티가 제공되지만, 주요 아이디어는 액션 객체에 대한 응답으로 상태가 시간이 지남에 따라 업데이트되는 방식을 설명하고 작성하는 코드의 90 %가 단순한 JavaScript이며 Redux를 사용하지 않는다는 것입니다 자체, API 또는 마술.

답변