Redux Basic

rhfovk·2021년 11월 3일
1

Internship

목록 보기
1/3
post-thumbnail

10월 한 달여 동안 플랜즈커피라는 회사에서 인턴십을 진행했다.
회사에서 사용하는 리덕스라는 상태관리 라이브러리와 미들웨어인 리덕스 사가를 학습하기 위해 세미나를 진행하고 그 세미나를 토대로 차근차근 블로그를 적어본다.

Redux?

리덕스는 대표적인 상태 관리 JavaScript 라이브러리이다.
리덕스를 사용하면, 컴포넌트들의 상태 관련 로직들을 다른 파일들로 분리시켜서 더욱 효율적으로 관리 할 수 있다.

또한, 컴포넌트끼리 상태를 공유하게 될 때 여러 컴포넌트를 거치지 않고도 손쉽게 상태 값을 전달 할 수 있다.


Redux 세 가지 원칙

1. 하나의 애플리케이션 안에는 하나의 스토어(store)

하나의 애플리케이션에선 단 한 개의 스토어를 만들어서 사용한다.
(여러 개의 스토어는 권장 X)

2. 읽기 전용 상태

내부적으로 데이터가 변경되는 것을 감지하기 위해 얕은 비교 검사를 하기 때문에 리덕스의 상태를 업데이트 할 때는 기존의 객체를 건드리지 않고 새로운 객체를 생성해주어야 한다.

읽기 전용 상태
리덕스에서 기존 객체를 건드리지 않고 불변성을 유지해야 하는 이유는 내부적으로 데이터가 변경 되는 것을 감지하기 위하여 shallow equality 검사를 하기 때문이다.
이를 통하여 객체의 변화를 감지 할 때 객체의 깊숙한 안쪽까지 비교를 하는 것이 아니라 겉핥기 식으로 비교를 하여 좋은 성능을 유지할 수 있는 것이다.
즉, 직접 객체를 변화시킨 것은 감지하지 못하며, 다시 렌더링 되지 않는다. 그래서 객체를 변화시키는게 아니라 새로운 객체를 만들고 새로운 값을 추가해야 한다.

3. 변화를 일으키는 함수, 리듀서는 순수한 함수

이전 상태와 액션 객체를 파라미터로 받는다.
똑같은 파라미터로 호출된 리듀서는 언제나 똑같은 결과를 반환한다.


Redux 기본 용어

  • 액션(Action)

    상태에 어떠한 변화가 필요하게 될 땐, 우리는 액션을 발생시킨다. 액션 객체는 type 필드를 필수적으로 가지고 있어야 한다.

  • 액션 생성함수 (Action Creator)

    액션 생성함수는, 액션을 만드는 함수이다. 단순히 파라미터를 받아와서 액션 객체 형태로 만들어 준다.

  • 리듀서 (Reducer)

    리듀서는 변화를 일으키는 함수이다. 리듀서는 두가지의 파라미터를 받아온다.
    리듀서는 현재의 상태와, 전달 받은 액션을 참고하여 새로운 상태를 만들어서 반환한다.

  • 스토어 (Store)

    스토어는 내부적으로 리듀서와 애플리케이션 상태, 이벤트 리스너 그리고 현재 디스패칭(Dispatching) 여부를 나타내는 값을 관리한다.

Redux 흐름

일반적으로 UI는 리덕스 안에 있는 상태를 받고, 액션을 만들어서 dispatch하고 이 dispatch된 액션을 리듀서를 통해서 새로운 상태를 업데이트하도록 한다.


Why Redux?

MVC패턴 - 양방향

그렇다면 리덕스는 왜 만들어졌을까?

  • Model : 데이터 형식이나 구조를 관리
  • View : 코드가 사용자에게 보여지는 부분을 담당
  • Controller : 변화하는 데이터를 관리

React 라이브러리로도 state관리를 충분히 진행할 수 있었음에도 불구하고, 새로운 라이브러리를 만든 이유는 무엇일까? 개발 패턴에 숨겨져 있다. 리덕스가 등장하기 이전 프론트엔드에서 데이터의 흐름을 관리하는 방식은 MVC 패턴이었다.

컨트롤러는 모델의 데이터를 조회하거나 업데이트하는 역할을 하며, 모델의 변화는 뷰에 반영된다. 그리고 사용자가 뷰를 통해 데이터를 입력하면, 모델에 영향을 주면서 데이터를 관리하게 된다.

하지만 사용자와의 상호작용이 굉장히 많아지고 있는 요즘의 웹사이트에서 특히, state관리가 복잡해짐에 따라 실시간으로 구동되어야 하는 기능이 제대로 이뤄지지 않아, state 차이로 인한 버그가 발생하는 등 다양한 문제점이 존재하였다.

이것의 가장 큰 원인은 바로, '양방향 데이터 흐름' 이라는 점!

Flux 아키텍처 - 단방향

그래서 위와 같은 문제점을 해결하기 위해서 '단방향 데이트 흐름'인 flux를 페이스북 사에서 개발하게 된다.

View는 MVC 패턴과 달리 데이터를 직접 변경시키지 않고 Action만을 넘겨준 후, View에서 이뤄진 Action은 반드시 Dispatcher를 거쳐 데이터 변경을 진행하게 된다.

이러한 아키텍쳐에 reducer를 더해 만들어진 것이 리덕스 인 것!

context API

그런데 사람들이 러닝커브를 크게 느끼는 리덕스를 굳이 사용해야할까?

답은 NO!

단순히 글로벌 상태를 사용하고자 한다면 리액트의 Context API 만으로도 충분히 구현을 할 수 있다.

context API는 일반적으로 상태관리를 useContext와 useReducer 훅으로 하게 되는데, createContext로 context의 기본값을 설정 후 Provider 라는 컴포넌트에 value값으로 각 컴포넌트에 state를 쓸 수 있게 된다.
useContext를 통해 값을 불러내 state와 dispatch를 정의한 useReducer 를 통해 새로운 state를 만들고 업데이트 하게 된다.

하지만 그럼에도 리덕스가 주요한 상태 관리 라이브러리로 쓰이는 이유는 무엇일까?

리덕스와 context API의 주요 차이는 성능 면에서 나타나게 된다. 리덕스에서는 컴포넌트에서 글로벌 상태의 특정 값을 의존하게 될 때 해당 값이 바뀔 때에만 리렌더링이 되도록 최적화가 되어있다.

반면 Context에는 이러한 성능 최적화가 이뤄지지 않았다. 컴포넌트에서 만약 Context의 특정 값을 의존하는 경우, 해당 값 말고 다른 값이 변경 될 때에도 컴포넌트에서는 리렌더링이 발생하게 된다.

서로 관련이 없는 상태라면 같은 Context 에 있으면 안되고, Context를 따로 따로 만들어주어야 한다.(내가 생각하기에는 매우 귀찮은 작업)

따라서, 글로벌 상태가 다양해지는 경우는 Context 의 사용은 적합하지 않을 수 있다.

그리고 또 하나의 차이는 미들웨어이다. 이 미들웨어에 관해서는 다음 글을 통해 알아보도록 한다.


출처 📚


https://react.vlpt.us/
https://devlog-h.tistory.com/26
https://ridicorp.com/story/how-to-use-redux-in-ridi/
https://brunch.co.kr/@linterpreteur/27

profile
말이 잘 통하는 프론트 엔드 개발자를 지향합니다.

0개의 댓글