on
[React] 게시판 만들기 3일차(feat. Redux)
Redux에 대해 잘 알지 못한 상태에서 바로 게시판 프로젝트에 적용해보려다가 어려움이 있어서 먼저 사전 학습을 한 뒤에 진행해야겠다고 생각했다.
그래서 오늘은 Redux 이론 공부를 먼저 하려고 한다.
Redux를 왜 쓸까?
예전에 부트캠프 기간 동안에 Recoil을 사용해 본 적이 있다.
이때는 주로 Props Drilling이 발생하는 경우나자주 사용하는 api의 값을 저장해 두었다가 사용하는 용도로 사용해보았다.
그런데, 이런 Redux, Recoil은 왜 사용하는 것일까?
참고 글
프로젝트가 커지다 보면 컴포넌트의 깊이가 점점 깊어지게 된다. React는 부모에게서 자식에게로만 단방향으로만 Props를 전달할 수 있다. 이런 특성 상 최상위 컴포넌트에서 최하위 컴포넌트에 props를 전달하려고 하면 코드량도 많아지고 알아보기가 점점 어려워진다. props값이 어디서부터 시작되었는지 4~5단계 부모 컴포넌트를 올라가다 보면 정신이 아득해지기 일쑤이다..
그리고 자식 컴포넌트가 아닌 컴포넌트에는 props로 값을 전달 할 수 조차 없기 때문에, state 끌어올리기를 해야하는 경우도 있다.
내가 경험한 바로는 이런 문제를 해결하기 위해 Redux와 같은 상태관리 라이브러리를 사용한다고 생각한다.
리덕스 공식 페이지에서 Redux를 사용해야 하는 이유를 이렇게 말하고 있다.
어느 시점에서는 프로그래머조차 애플리케이션에서 무슨 일이 일어나는지 알 수 없게 됩니다. 상태를 언제, 왜, 어떻게 업데이트할지 제어할 수 없는 지경에 이르고 맙니다. 시스템이 불투명하고 비결정적일 때 버그를 재현하거나 새로운 기능들을 추가하기란 매우 어렵습니다.
더욱 안 좋은 소식은 프론트엔트 제품 개발에 있어서 새로 갖춰야할 요건들이 늘어나고 있다는 점입니다. 이러한 예로 낙관적 업데이트(Optimistic update), 서버 렌더링, 라우트가 일어나기 전에 데이터 가져오기 등이 있습니다. 프론트엔드 개발자들은 이전에 겪어보지 못 했던 복잡한 상황에 둘러싸여 있습니다. 이제 포기할 때가 된 걸까요?
Redux란?
자바스크립트 앱을 위한 예측 가능한 상태 컨테이너
Redux는 React에서만 동작하는 라이브러리가 아니다. 바닐라 자바스크립트, Vue에서도 사용이 가능하다.
Redux 3가지 원칙
1. 하나의 스토어
- 하나의 애플리케이션에 하나의 store(글로벌 스테이트)를 만들어서 사용하길 권유 하고 있다.
2. 읽기 전용
- 기존에 있는 상태의 일부를 변경하여 mutation 하지 말라고 권고 하고 있다. 기존의 스테이트 객체를 수정하지 않고 아예 새로운 상태를 생성하여 업데이트 해야한다.
- 그 이유 중에 하나로 리덕스가 shallow equality를 하기 때문이라고 한다.
3. 리듀서는 순수한 함수여야 한다.
- 순수한 함수라는 말이 조금 익숙하지 않게 다가오는데, 참고한 블로그 글을 빌려오자면
리듀서 함수는 이전 상태와, 액션 객체를 파라미터로 받습니다. 이전의 상태는 절대로 건들이지 않고, 변화를 일으킨 새로운 상태 객체를 만들어서 반환합니다.똑같은 파라미터로 호출된 리듀서 함수는 언제나 똑같은 결과값을 반환해야만 합니다.
new Date() 를 사용한다던지… 랜덤 숫자를 생성한다던지… 혹은, 네트워크에 요청을 한다던지! 이런 작업들은 순수하지 않은(?) 작업이기 때문에 리듀서 함수의 바깥에서 처리를 해줘야 한다고 한다..