리듀서 로직 분리하기

실질적인 애플리케이션에서 모든 업데이트 로직을 단일 리듀서 함수에 넣으면 빠르게 유지보수가 어려워집니다. 함수의 적절한 길이에 대한 단일 규칙은 없지만, 일반적으로 함수는 비교적 짧아야 하며 이상적으로는 한 가지 특정 작업만 수행해야 한다는 데 동의합니다. 따라서 매우 길거나 여러 가지 작업을 수행하는 코드 조각을 가져와 이해하기 쉬운 작은 조각으로 나누는 것이 좋은 프로그래밍 관행입니다.

Redux 리듀서는 단순히 함수이므로 동일한 개념이 적용됩니다. 리듀서 로직 일부를 다른 함수로 분리한 다음, 부모 함수에서 새 함수를 호출할 수 있습니다.

이러한 새로운 함수는 일반적으로 다음 세 가지 범주 중 하나에 속합니다:

여러 곳에서 필요할 수 있는 재사용 가능한 로직 조각을 포함하는 작은 유틸리티 함수 (특정 비즈니스 로직과 실제로 관련이 있을 수도 있고 없을 수도 있음)
특정 업데이트 케이스를 처리하기 위한 함수로, 일반적인 (state, action) 쌍 외에 다른 매개변수가 필요한 경우가 많음
상태의 특정 조각에 대한 모든 업데이트를 처리하는 함수. 이 함수들은 일반적으로 전형적인 (state, action) 매개변수 시그니처를 가짐

명확성을 위해 다음 용어들을 사용하여 다양한 함수 유형과 사용 사례를 구분하겠습니다:

reducer: 시그니처가 (state, action) -> newState인 모든 함수 (즉, Array.prototype.reduce의 인자로 사용될 수 있는 함수)
root reducer: 실제로 createStore의 첫 번째 인자로 전달되는 리듀서 함수. 리듀서 로직 중 (state, action) -> newState 시그니처를 반드시 가져야 하는 유일한 부분
slice reducer: 상태 트리의 특정 조각 업데이트를 처리하는 데 사용되는 리듀서로, 일반적으로 combineReducers에 전달하여 구현
case function: 특정 액션의 업데이트 로직을 처리하는 데 사용되는 함수. 실제로 리듀서 함수일 수도 있고, 제대로 작동하려면 다른 매개변수가 필요할 수도 있음
higher-order reducer: 리듀서 함수를 인자로 받거나 결과로 새 리듀서 함수를 반환하는 함수 (combineReducers나 redux-undo 같은 경우)

"sub-reducer"라는 용어도 다양한 논의에서 루트 리듀서가 아닌 모든 함수를 의미하는 데 사용되었지만, 이 용어는 매우 정확하지 않습니다. 일부 함수를 "비즈니스 로직" (애플리케이션별 동작과 관련된 함수)이나 "유틸리티 함수" (애플리케이션별이 아닌 일반 함수)라고 부르는 경우도 있습니다.

복잡한 프로세스를 더 작고 이해하기 쉬운 부분으로 분해하는 것은 일반적으로 기능 분해(functional decomposition) 라는 용어로 설명됩니다. 이 용어와 개념은 모든 코드에 일반적으로 적용할 수 있습니다. 그러나 Redux에서는 접근법 #3을 사용해 리듀서 로직을 구조화하는 것이 매우 일반적입니다. 여기서 업데이트 로직은 상태 조각을 기반으로 다른 함수에 위임됩니다. Redux는 이 개념을 리듀서 구성(reducer composition) 이라고 부르며, 리듀서 로직을 구조화하는 데 지금까지 가장 널리 사용되는 접근 방식입니다. 사실, 이 방법이 너무 흔해서 Redux에는 combineReducers()라는 유틸리티 함수가 포함되어 있으며, 이 함수는 상태 조각을 기반으로 다른 리듀서 함수에 작업을 위임하는 프로세스를 특별히 추상화합니다. 그러나 이것이 사용할 수 있는 유일한 패턴은 아니라는 점을 유의해야 합니다. 사실, 세 가지 접근 방식을 모두 사용해 로직을 함수로 분할하는 것이 전적으로 가능하며, 일반적으로 좋은 방법이기도 합니다. 리듀서 리팩토링 섹션에서 이에 대한 몇 가지 예를 확인할 수 있습니다.