search

3-1-기본-리듀서-구조

리듀서는 createStore로 전달한 첫 번쨰 매개변수인 하나의 함수라는 것을 이해해야 한다.

리듀서가 하는 일

  • 첫 호출 때 state는 undefined라서 초기값을 지정하여 액션 발생 전에 이 케이스에 대해 처리해줘야 한다.

  • 실제 변경 일어나면 업데이트된 데이터로 만들어져야할 새로운 객체와 배열을 만들어 반환

  • 변경이 필요하지 않다면 기존 상태 반환

function counter(state = 0, action) {
  switch (action.type) {
    case 'INCREMENT':
      return state + 1;
    case 'DECREMENT':
      return state - 1;
    default:
      return state;
  }
}

위에꺼 전형적인 리덕스 리듀서 기본 구조이다.

  • if/else 빠르게 무거워지니까 switch 사용

  • 기존 데이터가 없는 경우 ES6의 default parameter 문법 사용

  • 액션에 따른 업데이트 처리

hashtag
기본적인 상태의 형태

리덕스는 관리해야 할 데이터를 가진다. 이 데이터의 형태는 리듀서의 로직을 구성하는데 중요한 역할을 한다.

리덕스의 상태는 상태 트리의 제일 꼭대기에 일반적인 js 객체를 가진다. 꼭대기 객체의 데이터를 구성하는 일반적인 방법은 최상위 키를 연관된 "도메인"이나 "조각"을 나타내는 서브 트리로 나누는 것이다.

todos와 visibilityFilter는 모두 상태의 최상위 키이며 특정 개념에 대한 상태의 조각이다.

보통 애플리케이션의 데이터 종류는

  • Domain data: 애플리케이션으로 보여주거나 사용, 수정할 데이터 (서버에서 가져온 모든 Todos)

  • App Data: 애플리케이션 동작을 위한 데이터(ex. 현재 Todo #5가 선택됨 혹은 Todos를 가져오는 요청이 있습니다와 같은 것들)

  • UI State: 현재 UI가 어떻게 보일 것인가에 대한 데이터(EditTodo Modal 상자가 현재 열려 있음)

스토어는 앱의 핵심이기 때문에 상태는 UI 컴포넌트가 아닌 도메인데이터와 앱의 상태에 따라 구성해야 한다. state.leftPane.todoList.todos의 형태는 좋지 못하다. todos는 그저 UI의 한 부분이 아닌 전체 앱의 중심이기 때문이다.

드물게 UI트리와 상태 트리가 1대1 대응인 경우가 있다. 이 경우는 다양한 UI 데이터의 양상을 리덕스 스토어에서 추적하는 경우다. 하지만 그 때 역시 UI 데이터와 도메인데이터의 모양은 다를 것이다.

전형적인 앱 상태의 형태는 다음과 같다.

hashtag
Summary

리덕스는 관리해야 할 데이터를 가진다. 이 데이터의 형태가 리듀서 로직 구성하는데 중요한 역할을 한다.

데이터 구성 방법은

  • 최상위 키를 연관된 도메인으로 나누기

  • 혹은 조각을 나타내는 서브 트리로 나누기

    • 특정 개념에 대한 상태의 조각

일반적인 데이터 종류

  • domain data

  • app data: 동작을 위한 데이터 (todo#5가 선택됨, 현재 todo 요청 중 등)

  • ui state: 현재 UI 보이는 방식

주의할점은

  • 상태는 UI 컴포넌트가 아닌 도메인데이터와 앱의 상태에 따라 구성해야 한다.

    • 예를 들어, state.leftPane.todoList.todos의 형태는 좋지 못하다. todos는 그저 UI의 한 부분이 아닌 전체 앱의 중심이기 때문이다.

Previous3-4-combineReducerNext2-1-1-advance-action

Last updated

Was this helpful?