기존의 2탄까지는 일종의 리덕스의 초기 셋팅을 알아봤다면, 이번에는 리덕스를 직접적으로 컴포넌트 단에서 어떻게 사용하는 지 기본적인 사용법에 대해 써보겠다.

1.UseSelector, Usedispatch.

1) UseSelector

먼저, 일전에 설명드렸듯이, 기존 리덕스에서는 구독이라는 subscribe 개념이라고 생각하면 되겠다. 리액트 리덕스에서 제공하는 일종의 간편한 훅이다. 이 훅을 통해 우리는 최 상단의 스토어에서 스테이트를 직접적으로 가져와서 사용할 수 있다. 사용법은 다음과 같다.

이렇게 유즈 셀렉터 훅을 임포트 시켜온 뒤에, 변수로서 사용할 스테이트 값을 지정한다. 그리고 useSelector 함수 내부에 콜백 함수 형태로 적어주면 된다. 인자는 보통 스테이트가 들어간다. 이 스테이트는 결국 우리가 일전에 설정한, 모듈화 된 구조의 리듀서다.

즉, 카운터라는 리듀서의 state내부 중에서 어떤 값을 받아올 지 결정하는 구조다. 뒤에 이제 리턴 값으로 결국 초기 스테이트 값 중에 어떤 값을 가져올 것인지 선택해서 반환해 주면, 끝이다.

그러면, 이제 컴포넌트는 이 초기 값을 가지고 화면에 뿌려주거나, 하는 등의 상태 값을 가지고 할 수 있는 작업이 가능하다.

즉, 여기서 중요한 점은.

뎁스의 깊이와 상관 없이, 어떤 컴포넌트 던 간에 유즈 셀렉터를 통해 스토어 내부에 상태 값을 가져올 수 있다는 편리함이다.

2)UseDispatch.

자~ 다음은 useSelector만큼이나 중요한, 유즈 디스패치다. 유즈 디스패치 역시 리액트 리덕스에서 제공하는 훅스다. 이 훅스는 말그대로 디스패치의 역할이다. 바로 사용법부터 보는 것이 이해가 쉬울 것 같다.

먼저, 셀렉터와 같이 훅스를 임포트 시켜준다. 그리고, 다음으로 컴포넌트 내부에서 쓸 수 있도록 dispatch라는 변수로 훅스를 정의해 준다. 그 아래에 이제 디스패치 함수를 설정을 해주면 된다. dispatch 내부에서도 역시 일종의 콜백 함수를 부른다. 위에서 임포트 해온 함수들은 결국 counter 리듀서 내부의 액션 함수들이다. 그래서 이 액션 함수들이 상황에 맞게 들어가고 호출된다고 보면 되겠다.

2. 랜더링 단에서의 사용.

이제 선언한 값들을 실제 사용 예제를 통해서 어떻게 사용하는 지, 한 번 보여드리겠다.

1) 랜더링 되는 부분에 직접적인 사용.

먼저, 가장 기본적으로 스테이트 값들은 바로 화면에 보여지는 랜더링 단에서 사용이 가능하다. 사용도 쉽다.

셀렉터를 불러오고, 그 값을 바로 아래처럼 변수화 시켜서 담아주면 끝이다.

이를 통해 우리는 별다른 조치 없이 스토어의 상태 값을 구독하며, 상태 값이 변경됨에 따라 화면의 랜더링 역시 자동적으로 이뤄진다.

2) 이벤트에 따른 상태 변화.

앞서 설명드린 것처럼, 유즈 디스패치를 통해, 우리는 상태 값의 변화를 리듀서에 전달해서 원하는대로 바꿀 수 있다.

위의 예시에서는 선택되는 값의 이벤트로서 selecting이라는 함수가 실행되게 설정되어져 있다. 이 셀렉팅은 결국 아까 말씀드린, 이 유즈 디스패치가 쓰이는 함수다.

이 함수 내부에서는 다른 로직은 없고, 조건문에 따른 어떤 디스패치 액션을 부를 것인지에 대한 로직만 나와있다. 이를 통해 컴포넌트 내부에서는 상태 값을 변경하는 로직이 없다. 즉, 리듀서 내부에서만 이 로직이 작동하는 것이다.

자. 이 쯤에서 다시, 카운터라는 리듀서의 로직을 다시 살펴 보자.

보시는 것처럼, 리듀서 내부에서 선택한 선지에 따라, 스테이트 값이 변경되도록 새로운 스테이트 값들을 정의해 주고 있다. 이를 통해, 리듀서는 액션의 값에 따라 조금씩 다른 로직을 처리하고 있으며, 기존의 스테이트에 변경된 스테이트 값을 덮어 씌우고 있다.

예시에서는 선택된 단어에 따라 그 값이 맞으면 맞은 개수를 하나 올리고, 다음 문제로 넘어간다. 그리고 맞은 것의 여부는 또 true로 만든다. 반대로 틀리면 반대의 값들이 하나씩 변경되고, 다음 문제의 인덱스로 올라가는 것은 동일하다. 이런 식으로, 하다보면, 마지막 문제 인덱스에 도달 시에, 파이널 액션으로 더는 문제 풀이 여부의 상태 값인 isCompleted를 true로 바꿔준다.

이런 식으로 어떤 액션에 따라 스토어의 상태 값은 바뀌고, 그 스토어의 상태를 구독하고 있는 컴포넌트들 역시 상태 값에 따라 재랜더링이 되는 구조다.

3. 다시 정리.

이렇게, 정말 간단한 구조의 리덕스 구조를 살펴봤다. 사실 이외에도 비동기 처리 등을 하는 리덕스 thunk나 사가 등이 있지만, 그 부분은 추후에 기회가 된다면 다루도록 하겠다. 현재는 기본적인 리덕스의 상태 관리 구조만 살펴봤다.

물론, 필자가 이렇게 설명드렸지만, 직접적으로 써보고 여러 에러를 겪어봐야만 더 잘 사용하실 수 있을 것이다.

그리고, 필자는 최근에 리덕스 외에 다른 상태 관리 라이브러리에도 관심이 생겨 그 부분에 대해서도 공부중이다.

그래서 추후에는 아마 최근 가장 떠오르는 상태 관리 중 하나로 꼽히는 리코일에 대해서 한 번 연재해 보고자 한다. 그러면서 리덕스와 다른 장단점에 대해서도 한 번 적어보겠다.

그러면 이번 리덕스 기본편은 여기서 마치겠다. 감사하다.