[ React + redux 01 ] 애플리케이션 상태관리 - 작업환경 설정

01. 리덕스로 리액트 애플리케이션 상태관리

리액트 애플리케이션에서 상태관리를 할 때 소규모 프로젝트에서는 컴포넌트가 가진 state 기능을 사용하는 것으로 충분할지 모르지만,

규모가 커지면 관리하기가 번거로울 수 있다.

상태관리 라이브러리를 따로 사용하지 않고 state만 사용한다면 다음 문제점이 발생할 수 있다.

• 상태 객체가 너무 복잡하고 크다.
• 최상위 컴포넌트에서 상태관리를 하는 메서드를 너무 많이 만들어 코드가 복잡해진다.
• 하위 컴포넌트에 props를 전달하려면 여러 컴포넌트를 거쳐야 한다.

이전 공부에서는 리덕스의 기초를 알아 봤다,

리덕스에서 함수를 스토어에 구독시킬 때 store.subscribe 함수를 사용했고, store.getState 함수를 사용하여  상태를 가져왔다.

리액트에서 리덕스를 연동할 대는 이런 함수들을 직접 사용할 일이 많지 않다.

공식 라이브러리인 react-redux가 컴포넌트에서 리덕스를 구독하는 작업을 하기 때문이다.

이번 공부는 생성과 제거 버튼을 만들어 카운터의 갯수를 조절하며, 동시에 여러 개의 상태를 관리하는 애플리케이션을 만듬으로써

리액트에서 리덕스를 사용하는 방법을 알아볼 것이다.

02. 작업환경 설정

2-1. 작업환경 설정 및 프로젝트 초기화, 디렉터리 생성

create-react-app을 이용한 프로젝트 생성

$ create-react-app redux-counter

프로젝트가 생성되면 redux-counter 디렉토리로 이동하여, yarn을 사용하여 redux와 react-redux를 설치한다.

$ yarn add redux react-redux

react-redux는 리액트 컴포넌트에서 리덕스를 더욱 간편하게 사용할 수 있게 하는 라이브러리 이다.

설치를 완료한 후 에디터로 해당 프로젝트 디렉터리를 열어 본다

진행에 앞서 src 디렉토리 내부에는 우리에게 필요없는 파일들이 있다. 아래 파일들을 제거하자.

• App.css
• App.js
• App.test.js
• logo.svg

src 디렉터리 내부에 아래 와같이 새 디렉터리들을 만들자

• actions : 액션 타입과 액션 생성자 파일을 저장한다.
• components : 컴포넌트의 뷰가 어떻게 생길지만 담당하는 프리젠테이셔널(presentational) 컴포넌트를 저장한다.
• containers : 스토어에 있는 상태를 props로 받아오는 컨테이너(container) 컴포넌트들을 저장한다.
• reducers : 스토어의 기본 상태 값과 상태의 업데이트를 담당하는 리듀서 파일들을 저장한다.
• lib : 일부 컴포넌트에서 함께 사용되는 파일을 저장한다.

2-2. 프리젠테이셔널 컴포넌트와 컨테이너 컴포넌트

프리젠테이셔널 컴포넌트와 컨테이너 컴포넌트는 리덕스를 사용하는 프로젝트에서 자주 사용하는 구조이다.

이 구조는 멍청한(dumb) 컴포넌트와 똑똑한(smart) 컴포넌트라고도 알려져 있다.

2-2_1. 프리젠테이셔널 컴포넌트

프리젠테이셔널 컴포넌트는 오직 뷰만 담당한다. 안에 DOM 엘리먼트와 스타일이 있으며,

프리젠테이셔널 컴포넌트나 컨테이너 컴포넌트가 있을 수도 있다. 하지만 리덕스 스토어에 직접 접근할 권한은 없으며,

오직 props로만 데이터를 가져올 수 있다. 또 대부분은 state가 없다. 있다고 해도 데이터와 관련된 것이 아니라 UI와 관련된 것이여야 한다.

주로 함수형 컴포넌트로 작성하며, state가 있어야 하거나 최적화를 하려고 라이프사이클 메서드가 필요할 때는 클래스형 컴포넌트로 작성된다.

2-2_2. 컨테이너 컴포넌트

이 컴포넌트는 프리젠테이셔널 컴포넌트들과 컨테이너 컴포넌트들의 관리를 담당한다. 내부에 DOM 엘리먼트를 직접적으로 사용할 때는 없고,

감싸는 용도일 때만 사용한다. 또 스타일도 가지고 있지 않아야 한다. 스타일은 모두 프리젠테이셔널 컴포넌트에서 정의해야한다.

상태를 가지고 있을 대가 많으며, 리덕스에 직접 접근할 수 있다.

2-2_3. 이 구조의 장점

컴포넌트를 이렇게 두 카테고리로 나누면 장점이 있다. 사용자가 이용할 유저 인터페이스와

상태를 다루는 데이터가 분리되어 프로젝트를 이해하기 쉽고, 컴포넌트 재사용률도 높다.

2-2_4. 오해

컨테이너 컴포넌트라고 해서 무조건 내부에 컴포넌트가 여러개 있어야 하는 것은 아니다.

예를 들어 Item이란 프리젠테이셔널 컴포넌트가 있다면 ItemContainer라는 컨테이너 컴포넌트를 만들어서, 

그 안에 단일 Item만 넣고 데이터를 연결해도 무방하다.

또 프리젠테이셔널 컴포넌트 내부에 컨테이너 컴포는트를 넣어도 된다. 예를 들어 템플릿 관련 프리젠테이셔널 컴포넌트를 만들고,

그 안에 여러가지 컨테이너 컴포넌트를 넣을 수도 있을 것이다.

어떤 것을 컨테이너로 만들지, 이 구조를 어떻게 사용할지는 자유이다. 리덕스를 사용한다고 해서 이구조를 무조건 따를 필요도 없다.

이는 리덕스의 창시자인 댄 아브라모프(Dan Abramov)가 더 나은 설계를 하려고 공유한 구조이기는 하나. 무조건 따라야할 규칙은 아니다.

따라하면 유용한 팁일 수 있겠지만, 어쩌면 개발초기에는 본인의 개발 흐름에 어울리지 않을 수도 있다.

무조건 프리젠테이셔널 컴포넌트로 분리하지 말고, 그냥 DOM 엘리먼트를 지닌 컴포넌트에 직접 리덕스를 연결해도 상관없다.