Skip to content

Latest commit

 

History

History
120 lines (90 loc) · 4.84 KB

4주차_조명근_공통.md

File metadata and controls

120 lines (90 loc) · 4.84 KB

4주차 조명근 공통

공통: 리덕스 붐이 다시올까?

개요

image 아무리 까여도 굳건하게 자리를 지키고있다. 심지어 최근에는 다운로드수가 더 올라가는 모습.

redux는 페이스북(메타)이 react를 위해서 발표한 Flux 패턴을 바탕으로 상태관리를 목적으로 개발된 오픈소스이다. Flux 패턴은 액션을 통해 상태를 변경하고, 변경된 상태가 View를 갱신하며, 단방향으로 데이터가 흐르는 아키텍쳐 패턴 이라고 볼 수 있다.

저 한 문장을 실현하기 위해 redux는 몇 가지 주된 개념을 가진다.

Store

상태를 저장하는 단일 객체

import { createStore } from "redux";
import { counterReducer } from "./counterSlice";
import { composeWithDevTools } from "redux-devtools-extension";

export const store = createStore(counterReducer, composeWithDevTools());

Action

상태 변경을 설명하는 객체.

// 이 자체로 Action
const incrementAction = {
  type: "counter/increment",
  payload: { amount: 1 },
};

// Action을 실행하는 함수
export function increment() {
  return { type: "counter/increment" };
}

export function decrement() {
  return { type: "counter/decrement" };
}

Reducer

상태를 업데이트하는 순수 함수
react 생명주기와 상관없기 때문에 내부에서 hook을 호출하는 등

// counterSlice.js
const initialState = { count: 0 };

export function counterReducer(state = initialState, action) {
  switch (action.type) {
    case "counter/increment":
      return { ...state, count: state.count + 1 };
    case "counter/decrement":
      return { ...state, count: state.count - 1 };
    default:
      return state;
  }
}

Dispatch / Subscribe

Displatch는 액션 실행시키는 트리거를 뜻한다. Subscribe을 통해 변경된 상태값을 View에 업데이트 시킨다.

// Counter.js
import React from "react";
import { useSelector, useDispatch } from "react-redux";
import { increment, decrement } from "./dispatch.js";

function Counter() {
  const count = useSelector((state) => state.count);
  const dispatch = useDispatch();

  const onClickIncrement = () => {
    dispatch(increment());
  };

  const onClickDecrement = () => {
    dispatch(decrement());
  };

  return (
    <div>
      <h1>Counter: {count}</h1>
      <button onClick={increment}>Increment</button>
      <button onClick={decrement}>Decrement</button>
    </div>
  );
}

export default Counter;

redux는 위에서 말한 Flux 패턴으로 단일 상태 흐름을 가진다.
각 역할군들의 수행하는 행위가 명확하기 때문에 디버깅에 용이하고, 커다란 상태관리에는 적합할지 모르겠지만, 이런 단순 상태변화를 굳이 커다란 boilerplate를 가진 redux를 사용해야하는지는 잘 모르겠다.

하지만 좀 더 복잡한, 그리고 여러 개발자가 작업해야하는 환경이라면?
정해진 규칙이 필요하고 비슷한 패턴으로 개발해야 유지보수에 용이할 것 이다.
그런면에서 Redux는 좋은 해답이 될 수 있다.
redux-toolkit을 같이 사용한다면 Server 상태관리, Client 상태관리를 분리해서 유지보수도 가능하고, 이벤트 기반으로 동작하는 구성또한 관심사 분리에 용이하다.

React같은 SPA 개념이 등장하고 Frontend가 단일 페이지에서 로드하는 Javascript 파일만 변경해서 속도나 UX 측면의 이점을 가져왔다고 본다.
마찬가지로 SPA 환경에서 연속성 있는 상태관리 방식이 필요했을 것 이고, Context API(react16.3, 2018)보다 redux(2015)가 먼저 등장했다.
Context API가 없었던 시절에도 전역 상태관리는 필요했고, redux는 단방향 데이터 흐름과 불변성 관리 의 철학을 가지고 주요 라이브러리로 자리잡았다.
전역 상태관리 단일 스토어로서 위 철학을 지키기 위한 필요 코드(Boilerplate)는 점점 복잡해졌고 복잡한걸 간단하게 만들기위한 작은 관점의 상태관리방법이 필요했다. 이때 등장한 zustand, jotai 등이 큰 관심을 받았다고 생각한다. 실제 zustand는 A small, fast, and scalable bearbones state management solution 이라고 소개한다. 작고 빠르며 확장 가능한 베어본(기본적인 것만 할 수 있는) 솔루션

그러면 redux의 붐은 다시 올까?
사실 redux를 사용해서 코드를 만들었을때 너무 불필요하고 복잡한 반복적인 행위들이 많았어서 기억이 좋지는 않다.
그래도 큰 규모의 Application을 많은 사람이 수정해야한다면 그 틀을 벗어나기는 쉽지 않기 때문에 적합하지 않을까?
event driven의 장점에는 xstate가 그 역할에는 더 어울리지 않을까?