리덕스 왜 쓰는데 ?!

풍부한 미들웨어

코린이들에겐 장점이면서 단점일 수 있다.

너무 많은 미들웨어 지식을 수용하기엔 코린이 뇌 용량은 과부하...

• 기본 리덕스만을 사용할 때 복잡해질 코드를 단순하게 사용할 수 있음
• 비동기 처리를 효율적으로 관리하고 유지 보수하기 용이함 (코린이 제외)

이미 만들어진 유용한 함수와 Hooks

• connect, useSelector, useDispatch, useStore 등

최적화

리덕스를 만드신 분들은 쌉고수 개발자들이시다.

코린이가 몇 시간 고생할걸 몇 분으로 해결할 수 있게 최적화가 잘 되어 있다.

하나의 커다란 상태

리덕스를 사용하는 가장 큰 이유는 아무래도 전역적인 상태 관리를 하기 위함이다.

밑도 끝도 없이 수심 100 미터까지 props를 내려주고 싶지 않다는 강력한 의지.

매번 컨텍스트를 만드는 수고로움을 피하겠다는 강력한 의지.

리덕스 데브 툴즈

리액트와 마찬가지로 개발자 도구를 제공한다.

리덕스 개발자 도구의 장점은 Action의 변화에 따라 시간 별로 state의 값을 이동할 수 있다는 것.

이미 사용중인 프로젝트가 많다

솔직히 코린이라 얼마나 많은지 모르겠지만

npm trends만 보아도 많긴 할거 같다는 생각이 든다.

리덕스를 사용한 프로젝트가 많다면 배워서 나쁠건 없다.

그렇다면 리덕스 언제 써야하지

• Q. 프로젝트의 규모가 큰가?

• Q. 비동기 작업을 자주하게 되나?

• Q. 리덕스가 편한가?

보통은 이 3가지 질문에 해당하는지 여부를 가지고 리덕스 사용을 고려해봐야한다는 많은 선배님들의 조언.

리액트도 겨우 이해하고 있는 코린이 입장에서 리덕스는 세렝게티 초원을 거닐다 만난 사자같은 존재지만

멘탈에 구멍 뚫려가면서 공부하니까 남는게 많은거 같긴 하다 이 흐름이 지속적으로 유지되길 바랄뿐...

아직 가야 할 길은 멀다.

리덕스에 사용되는 키워드

액션

액션 생성 함수에 의해서 하나의 객체로 만들어진다.

타입이라는 속성을 필수로 가지고 있어야 나중에 리듀서라는 함수에서 타입을 보고 state를 어떻게 업데이트할지 결정할 수 있다.

액션 생성함수

액션을 생성해주는 함수이다.

함수에 특정 데이터가 들어오면 같은 타입의 액션 객체를 반환한다.

export function addTodo(data) {
  return {
    type: "ADD_TODO",
    data
  }
}

리듀서

state에 변화를 주는 함수이다.

조직의 우두머리 같은 느낌이랄까.

하지만 얘도 action 객체가 없다면 존재 의미가 없어진다.

리덕스의 모든 요소들은 서로 긴밀한 관계를 가지고 있다.

function couter(state, action) {
  switch(action.type) {
    case "INCREASE":
      return state + 1;
    case "DECREASE":
      return state - 1;
    default:
      return state;
  }
}

스토어

한 애플리케이션에 하나의 스토어를 가질 수 있고

스토어에는 현재 앱에서 사용하는 함수와 리듀서 및 내장함수를 가지고 있다.

디스패치

dispatch(addTodo(data));

액션을 발생시키는 함수, 즉 트리거 함수.

디스패치에 액션생성함수를 실행시켜 실행하면(?) 빵야빵야

그럼 이 탄환은 어디로 간다? 리듀서로 간다.

리듀서로간 탄환은 액션 타입에 맞춰 다음 상태 값을 가지고 일발 장전, 스토어에 꽂힌다.

• dispatch(action객체) => reducer => 스토어

구독(좋아요, 알림설정)

호출 할 때 파라미터로 특정 함수를 넣어주면 액션이 디스패치될 때 특정 함수 실행.

코린이 입장에서 너무 괴리감 느껴진다.

유튜브에 너무 중독되어 있어서 그런지 구독 좋아요 알림설정의 늪에서 빠져나오질 못 하겠다.

리덕스의 구독 부분은 차분히 더 공부를 해서 채워야 할 부분인 듯 하다.