[RN] 프로젝트를 진행하며 겪은 Props Drilling 문제, 그리고 Redux 분석

 

 

React-Native로 앱을 만드는 업무를 할당 받고
일단 화면을 만들어 내야 한다는 생각에
크게 고민 없이
가장 기본이 되는 hook(useState, useEffect),
그리고 props 로 필요한 정보를 넘겨가며
화면을 구성해 나갔다.
 
이런 방식으로 계속해서 코드를 짜다가
페이지 수가 점점 늘어나며
문득, 'Props Drilling'라는 문제점을 발견하게 된다.
 
.
.

 

이 글에서는 1주일 동안 react native로
앱을 만드는 프로젝트를 진행하며 알게된

 

react 의 특징 
그리고 내가 사용한 hook 이란 무엇인지,
 
Props Drilling 문제란 무엇이며
어디서 이런 문제가 발견되었는지,

그리고 Redux란 무엇인가,
Redux를 좀 더 편리하게 만든 라이브러리와의
그 차이는 무엇인지 등에 대한 내용을 담았다.

 

 

React 의 상태관리의 중요성

 

양방향 바인딩을 하는 다른 언어들과는 달리,

react는 단방향으로 바인딩을 하는 라이브러리 이다.

 

부모 -> 자식 방향으로만 state를 props로 전달할 수 있고,

자식의 props를 부모에게 전달하는 방법은 존재하지 않는다.

 

 

 

대신 자식 component에서 부모 component의 state를 

바꿀 수 있는 두 가지 방법이 존재한다.

 

 

1. 자식에게 부모의 state를 modify할 수 있는 setState함수를 props로 넘겨준다.

 

2. state management tool (redux, recoil)을 사용한다.

 

 

---

 
 

Hook의 개념 및 종류

 

React Hook이란?

 
React 에서 기존에 사용하던 Class를 이용한 코드를 작성할 필요 없이,
state와, 여러 React기능을 사용할 수 있도록 만든 라이브러리 이다.
 
이는 함수형 컴포넌트에서 React state와 생명주기(lifecycle fetures)를
연동(hook into) 할 수 있게 해주는 함수이다.
 
즉, 기존 클래스의 생명주기 메서드를 함수형 방식에서 함수로 사용할 수 있도록 한 것이다.
상태 값을 초기화하거나, 
변경이 발생했을 때 등의 상황에서 
리액트의 훅 함수가 호출되는 방식인 듯하다.
 
많은 종류의 hook들이 존재하지만
 
가장 기본이 되는 hook이기도 하고,
내가 현재까지의 프로젝트에서 가장 많이 사용한
useState, useEffect를 위주로 글을 적도록 하겠다.
 

1. useState

 
여기서 state란, react 에서 사용자의 반응에 따라, 화면을 바꿔주기 (렌더링) 위해 사용되는
트리거(자동으로 실행되는 프로시저) 역할을 하는 변수이다.
 
React가 state를 감시하고, 바뀐 정보에 따른 화면을 표시해 준다.
 

// React에 기본적으로 내장되어 있는 useState 훅을 사용하면, state를 만들 수 있다.
import { useState } from "react";
// const [state, state변경함수] = useState(기본 state값);
const [isLoggedIn, setIsLoggedIn] = useState(false);

 
다음과 같이 state를 만들 수 있다.
 isLoggedIn은 기본 state값, setIsLoggedIn은 state 변경함수를 뜻 한다.
 

// 전에 만든 "isLoggedIn" state의 값을 true로 변경한다.
setIsLoggedIn(true);
// ** useState함수를 사용해 만든 "state 변경 함수"를 사용하여야 한다.

 
전에 만든 isLoggedIn의 state 의 값을 true로 변경하는 코드이다.
이렇게 되면, isLoggedIn을 출력해보면, true로 찍히는 것을 볼 수 있다.
 

2. useEffect

 
useEffect() 함수는 React component가 렌더링 될 때마다 
특정 작업(Side effect)을 실행할 수 있도록 하는 리액트 hook이다.
 
여기서 side effect는 component가 렌더링 된 이후에 비동기로 처리되어야 하는 
부수적인 효과들을 뜻한다.
 
이러한 기능으로 인해 함수형 컴포넌트에서도 클래스 형 컴포넌트에서 사용했던 
생명주기 메서드를 사용할 수 있게 되었다.
 
useEffect는 component가 mount(생성), ummount(제거), update(업데이트) 되었을 때
특정 작업을 처리할 수 있다.
 
즉, 클래스 형 컴포넌트에서 사용할 수 있었던 생명주기 메서드를
함수형 컴포넌트에서도 사용할 수 있게 된 것이다.
 

 
- componentDidMount : 컴포넌트를 만들고, 첫 렌더링을 다 마친 후에 실행된다.
- componentDidUpdate : 리렌더링을 완료한 후 실행, 즉 render()가 업데이트 될 때마다 실행한다.
- componentWillUnMount : 컴포넌트를 DOM에서 제거할 때 실행한다.
 
 
[ useEffect 사용방식 ] 
 
1. componentDidMount
 
: Component가 mount 됐을 때(처음 나타났을 때 실행)
 

useEffect(() =>{
 console.log('마운트 될 때만 실행된다');
}, []);

 
: 컴포넌트가 화면에 가장 처음 렌더링 될 때 한 번만 실행하고 싶다면 deps 위치에 빈 배열을 넣어준다.
 

useEffect(()=>{
 console.log('렌더링 될 때마다 실행된다.');
});

 
: 만약 배열을 생략한다면 리렌더링 될 때마다 실행된다.
 
2. componentDidupdate
 
: Component 가 update 될 때 (특정 props, state가 바뀔 때 실행)
 

useEffect(()=>{
 console.log(name);
 console.log('업데이트 될 때 실행');
}, [name]);

 
: 특정 값이 업데이트 될 때 실행하고 싶다면 deps위치의 배열 안에 검사하고 싶은 값을 넣어준다.
(의존 값이 들어있는 배열 deps라고도 한다. dependency를 의미)
 
하지만 업데이트될 때만 실행하는 것이 아니라
마운트 될 때도 실행된다.
만약, 업데이트될 때만 실행시키고 싶다면?
 

const mounted = useRef(false);
useEffect(()=>{
 if(!mounted.current){
   mounted.current=true;
   } else{
     console.log(name);
     console.log('업데이트 될 때마다 실행');
   }
}, [name]);

 
이렇게 useEffect 훅과 useRef 훅을 활용하여 컴포넌트가 마운트 되었는지,
업데이트 되었는지에 따라 효과적으로 조건을 실행할 수 있습니다.
 
useRef훅을 사용하여 mounted라는 변경 가능한 참조를 만듭니다.
useEffect훅을 생성하여 초기 마운트와 후속 업데이트 시에 
서로 다르게 동작하도록 합니다.
초기 마운트에서는 mounted 참조를 true로 설정한다. 
후속 업데이트에서는 name 프롭 값을 로그하고 효과가 실행되었음을 나타내는 메시지를 출력한다.
 
 
3. componentDidUnMount
:  component가 unmount 될 때 (사라질 때) & update 되기 직전에 실행
 

useEffect(()=>{
  console.log('effect');
  console.log(name);
  return()=>{
   console.log('cleanup');
   console.log(name);
  }
 }, []);

 
cleanup 함수 반환(return 뒤에 나오는 함수이며, useEffect에 대한 뒷정리 함수라고 한다.)
 
1. 원마운트 될 때만 cleanup함수를 실행하고 싶다면, 두 번째 파라미터에 빈 배열을 넣는다.
2. 특정 값이 업데이트되기 직전에 cleanup함수를 실행하고 싶다면, deps 배열 안에 검사하고 싶은 값을 넣는다.
 
즉 컴포넌트가 재 사용 될 때마다 실행되며 모든 새로운 sideEffect 함수가
실행되기 전에(처음 실행 제외)
그리고 컴포넌트가 제거되기 전에 실행된다.
 
 

---

 
 
hook의 종류로는 useLayoutEffect, useContext, useMemo, useRef 등과 같은
더 많은 훅들이 존재하지만
가장 대표적인, 그리고 내가 지금까지 사용했던 useState, useEffect에 대해서만 간단히 알아보았다.
 
그리고 나는 대략적인 상태관리를 useState에 저장해서
props로 다른 컴포넌트로 전달하는 방식으로 코드를 짰다.
 
그런데 이런 것들을 사용하면서 문득 막히는 부분이 있었다.
 
일단 뭐가 되었든 이 페이지를 만드는 게 우선이라 생각되어,
급한 마음으로 필요한 컴포넌트를 넘기고.. 또 넘기고.. 또 넘기다 보니.. 문득
잠만.. 이게 맞나??
라는 생각이 들었다. 
현재에는 페이지가 몇 개 안 되어서 상관없겠지만
이게 페이지 수가 더 많아지면 답 없겠는데 싶었다. 
 
 
이것을 바로 
 
바로 Props Drilling라고 한다.
 
 

 
이는 프로퍼티 내리 꽂기, threading등으로 불린다.
 
props를 통해  데이터를 전달하는 과정에서 중간 컴포넌트는 
그 데이터가 필요하지 않음에도 
자식 컴포넌트로 전달하기 위해 
props를 전달하는 과정을 말한다.
 
또한 여러 컴포넌트가 동일한 상태에 액세스 하고 수정해야 하는 경우,
이러한 컴포넌트 간에 결합 때문에 코드를 어떻게 수정해야 할지도 몰라 막막함을 느꼈다.
 
 
이를 해결하기 위해 axiox로 계속 json요청을 해야 되나?
라고 생각 했지만,
그렇게 하면 성능문제, 데이터 불일치 문제, ui 깜박임 등의 문제들이 발생하게 된다고 한다.
 
 

그러면 어떻게 해결해야 할까?

 

상태관리 도구를 사용한다.
 
- 데이터를 필요로 하는 컴포넌트가 정말 깊숙이 위치하고 있다면,
React에서 제공하는 Context API를 사용하거나 Redux 등의
외부 상태관리 라이브러리를 사용해서 
문제를 해결할 수 있다.
 

---

 

Redux란?

 
React 의 대표적인 상태관리 라이브러리이다.
Redux는 애플리케이션에서 정교한 상태 관리를 구현하는 데 도움이 되는
라이브러리 중 하나이다.
 
Redux는 컴포넌트와 상태를 분리하는 패턴을 써서 
관리를 편하게 도와주는 도구이다.
 

 
간단하게 설명하면 이런 형태와 같다.

 

 

그리고 좀 더 자세히 보면 

이런 형태와 같다.

 

중요 키워드 및 개념

 

액션

 
: 사용자에 의해 상태의 변화가 생길 때 이것을 액션이 발생되었다고 한다.
아래와 같이 타입과 value로 이루어져 있다.
type은 무조건 들어가야 하며 value는 자유롭게 작성해도 된다.
 

{
  type: "PUSH_BUTTON"
  button: "pushed"
}

// 혹은

{
  type: "PUSH_BUTTON"
  isToggle: true
}

 
 

액션 생성함수

 
: 액션을 만드는 함수이다.
파라미터(data)를 받아와서 액션 객체 형태로 리턴해서,
사용자가 사전에 지정한 액션을 호출할 수 있게 한다.
 

export function pushButton(data) {
  return {
    type: "PUSH_BUTTON",
    data
  };
}

 
 

리듀서

 
변화를 일으키는 함수이다. useReducer()와 똑같은 형태를 가지고 있으며, 
현재의 상태(state)와 전달받은 액션(action)을 파라미터로 받고,
새로운 상태의 값(return +-1, 증분 된 값)을 반환한다.
 

// 카운터 기능을 예로 들었을 경우입니다.
function counter(state, action) {
  switch (action.type) {
    case 'INCREASE':
      return state + 1;
    case 'DECREASE':
      return state - 1;
    default:
      return state;
  }
}

 
액션에서 지정한 type을 switch-case로 확인하고,
전달받은state파라미터에 +1 또는 -1를 추가해서 반환한다.
 
이 현재의 state와 반환되는 state가 가장 중요하다.
 
먼저 아래 스토어(store)에 대해 확인해 보겠다.
 

스토어

 

 
리덕스에서 단 하나의 스토어를 만들게 되는데,
이 스토에 내부에는 현재의 앱 상태(State)와 리듀서(reducer)가 들어있다.
 
위와 같이 카운터를 만들었다고 가정하고, 리듀서 쪽에서 정의한 state를 다시 확인해 보자.
카운터로 인해 숫자가 늘어나고 줄어드는 텍스트박스(컴포넌트)가 있으며,
이 상태를 우리는 redux를 이용해 상태관리를 하려고 한다.
 
 
위 컴포넌트를 redux로 사용할 경우,
아래와 같이 useSelector()라는 함수를 이용해서 스토어에 저장된 현재의 상태를 가져와
초기화를 해준다.
 

  const count = useSelector((state: RootState) => state.counter.count);
  
  return (
  	<div>{count}</div>
  )

 
+1버튼을 누르거나 -1버튼을 누를 때, 디스패치(dispatch)라는 것을 통해 액션 생섬함수를 호출하도록 한다.
 
 

디스패치

 
디스패치는 스토어(store)에서 제공하는 함수 중의 하나로 액션을 발생시켜주는 도구이다.
 

const dispatch = useDispatch(); // 디스패치 함수를 가져옵니다

  // 각 액션들을 디스패치하는 함수들을 만들어줍니다
  const onIncrease = () => {
    dispatch(increase());
  };

  const onDecrease = () => {
    dispatch(decrease());
  };

 
위와 같이 디스패치 함수 안에서 액션 함수를 지정하고, 
onIncrease()(액션 생성 함수)를 호출하면, 액션 생성함수로 인해 액션이 생성되고,
그다음 리듀서가 호출되며 현재의 상태(텍스트 박스의 숫자가 3이면 3, 혹은 19이면 19)에 
리듀서에서 지정한 return state+1이 반환되며,
이 값이 스토어 (store)에 저장된다.
 
useSelector()는 스토어에 있는 값을 가져다가 텍스트 박스를 갱신시켜 주게 되고,
결과적으로 +1이 된 값이 사용자에게 보이게 된다.
 

 
이 흐름을 이해 했다면 
리덕스를 다 이해했다고 볼 수 있다.
 
 
 

리덕스의 장/단점 

 

리덕스의 장점

 
리덕스는 위 그림처럼 단방향으로 데이터가 흐른다.
즉, 버그를 예측하기 쉽다. 내가 어떤 액션을 실행하였고 어떻게 데이터가 흐르는지
예측이 가능하여 디버깅이 매우 용이하다.
그리고 기록이 남아서 이전 상태로도 되돌아갈 수 있다.
그리고 데이터의 중앙집권화이다.
 

리덕스의 단점

 
우선 코드 작성이 '초기에는 복잡'하다. 스테이트 업데이트에 맞는 액션 값들과
디스패치 함수들 그리고 리듀서들 등등
초기에 미리 전부 만들어 줘야 하는 복잡성이 있다.
 
위의 그림에선 단 2가지 상태값밖에 없지만 프로젝트가 커지고 복잡해지면 액션 값들이
몇십 개는 늘어날 것이다.
 
 
리덕스를 사용하면 좋을 때
 
리덕스 공식문서를 보면 이럴 때 사용하면 좋다고 나와있다.
 
- 앱의 여러 위치에서 필요한 많은 양의 상태들이 존재할 때 (전역 상태가 필요하다고 느껴질 때)
- 상태들이 자주 업데이트 될 때
- 앱이 중간 또는 큰 사이즈의 코드를 갖고 있고 많은 사람들에 의해 코드 관리가 될 때
- 상태가 업데이트되는 시점을 관찰할 필요가 있을 때
 
 

reduxjs/toolkit

 
redux의 개선 버전으로, 문법이 좀 더 쉬워 졌다.
 
 
1. configureStore를 사용하여 Redux Store 생성
 
store.js>
 

import { configureStore } from "@reduxjs/toolkit";
import todoReducer from './slices/todoSlice';

export const store = configureStore({
    reducer:{
        todo: todoReducer //생성한 reducer를 Store에 등록
    }
});

 
: state들을 보관하는 파일이다.
 
2. React 컴포넌트에 Redux Store 제공 순서
 
index.js>
 

import { Provider } from 'react-redux';
import {store} from './redux/store';
import MainScreen from './screens/MainScreen';

export default function App() {
  return (
    <Provider store={store}>
      <MainScreen/>
    </Provider>
  );

 
그리고 App 컴포넌트 아래 컴포넌트인 MainScreen 컴포넌트에 data및 state를 공급하기 위해
다음과 같이 Provider 컴포넌트에 store를 props로 전달해야 한다.
 
이때 생성한 store는 내장 모듈이 아니기 때문에
{}로 감싸서 모듈을 import 하는 것에 주의해야 한다.
 
3. createSlice로 Redux slice reducer 생성( Redux store에 state 보관하는 법)
 

const todoSlice = createSlice({
  name: "todo", 
  initialState: {
        currentId: 4,
        todos: [],
    }, //초기 state 정의
  reducers: {
    //state functions(add,delete,update 로직 구현 부)
  },
});
export default todoSlice.reducer;

 
해당 프로젝트에서는 add, update, delete에 관한 상태관리 함수가 필요하기 때문에
reducer 로 정의한다. 
 
4. useSelector로 데이터 읽고 state raise 하기
 

(Todo.js)

import { useSelector } from "react-redux"

function Todo(){
  let a = useSelector((state) => { return state } )
  console.log(a)

  return (생략)
}

 
아무 컴포넌트에서 useSelector((state) => { return state } ) 쓰면
store에 있던 모든 state가 그 자리에 남는다. 

let a = useSelector((state) => state.user )

 
이런 식으로 사용 가능하다.
 
5. store의 state 변경하는 법
 
5.1 addTodo()
 

addTodo: (state, action) =>{
  state.todos.push({
    id: state.currentId++,
    text: action.payload.trim(),
    state: 'todo',
  });
 },

 
 
5. 2 updateTodo()
 

updateTodo:(state, action) =>{
  const item = sstate.todos.findindex((item)=> item.id ===action.payload);
  state.todos[item].state = state.todos[item].state==='todo' ? 'done' : 'todo';
  state.todos.push(state.todos.splice(item, 1)[0]);
 },

 
5. 3 deleteTodo()
 

deleteTodo : (state, action)=>{
  const item = state.todos.findIndex((item)=> item.id===action.payload);
  if(item>-1){
   state.todos.splice(item, 1);
   }
  }

 
 
변경하고 싶은 컴포넌트에서 import 해와서 사용한다.
근데 이때, dispatch()로 감싸서 사용해야 한다.
그리고 dispatch(state 변경함수()) 이렇게 감싸서 실행하면 state가 변경된다.
 

  

---

  
본인이 진행하고 있는 프로젝트에 맞추어
라이브러리를 선택하면 될 것 같다.
 
Redux-toolkit 이외에도 
recoil, jotai 등등 다양한 라이브러리가 존재하고 있다.
 
그것들도 비교해보고 싶었지만
그건 다음 블로그에서 차차 다루도록 하겠다.

그럼 이만,,,