한지 - 한조각 쓸모있는 지식 레터

React 개발을 하다보면

state, props로는 depth가 너무 깊어지는

props drilling문제가 발생하는 시점이 온다.

또한,

단계별 진행이나 페이지 변경 후에도 상태를 유지해야 하는 List뷰 등에서

어려움을 겪게된다.

이러한 문제들을 해결해주는 것이

global state관리를 도와주는 라이브러리들이다.

그 중에서 local global state라고 부르도록 하겠다.

주요 상태관리 라이브러리

1. Context API

2. Recoil

3. MobX

4. Redux

위 4가지 정도가 있는데,

1에서 4로 갈수록 러닝커브가 높다고 생각하는 바이다.

그럼에도 각 장,단점이 있으니 알아보도록 하자.

1. Context API

ContextAPI는 4가지 중에 유일하게
React 내장 상태관리 기능이다.

즉, 별도의 라이브러리 설치 없이 사용 가능하다는 말이다.

Docs를 보고 처음 사용 하는 사람도
쉽게 적용할 수 있는 수준이니

러닝커브 또한 낮다고 할 수 있다.

ContextAPI가 처음 나왔을때는

언어설정이나 색상테마 등

잘 변경되지 않는 상태를 관리할때 쓰였다.

그러나 지금은

전역상태 관리로 사용하던

지역상태 관리로 사용하던

개발자의 자유일뿐

상태 관리 기능으로써 충분한 지원을 하고있다.

참고

그럼에도 다른 라이브러리들을

추가 설치해 사용하는 이유가 있다.

2. MobX

언급할 내용은 MobX뿐 아니라

Redux, Recoil등 다른 라이브러리들을

사람들이 사용하는 이유이다.

4가지 모두 상태관리라는 컨셉을 가지고 있지만 그 안에서 나뉘는 개별 특징들이 있다.

그중에 내게 맞는 특징을 갖는 라이브러리를 택하면 되는것이다.

MobX는 전역상태관리 기능을 제공한다.

뿐만 아니라 상태 업데이트 로직을 View Component 밖에서(코드 분리) 할 수 있도록 도와준다.

Redux에 비해 적은 보일러 플레이트 코드, 직관적인 코드를 갖는다는 특징도 있다.

다만, MobX에서는 여러개의 Store를 둘 수 있는데

그로인해 예상치 못한 업데이트 등이 발생할 수 있다는 단점아닌 단점이 있다.

3. Redux

Redux도 MobX와 마찬가지로

전역상태관리 + 상태 업데이트 로직 분리를 돕는다.

하나의 Store를 갖는 특징으로

상태가 업데이트 될때 정확하게(직관적으로)

해당하는 상태를 갖는 컴포넌트들만 업데이트 된다는 장점이 있다. (유지보수의 편안함)

다만, Redux는 비동기 처리를 위해

thunk, saga 등 추가적으로 라이브러리들이 붙게되고

보일러플레이트 코드가 너무 많아진다는 단점을 가지고 있다.

4. Recoil

최근 각광받고 있는 Recoil은

react를 개발/운영하고 있는 Facebook(Meta)에서 개발한 만큼

가장 react 친화적이라는 장점을 가지고있다.

뿐만 아니라 매우 사용 방법이 매우 간단하고 직관적이다.

ContextAPI가 상태를 일일이 만들어야 하는 과정을 가진데 반해

Atom을 통해 매우 간결하게 상태관리를 할 수 있다.

캐싱을 통한 최적화 기능은 보너스이다.

최근,

이직 준비를 하며 많은 기업들에서 Recoil을 도입하고 있는것을 보게되었다.
사이드 프로젝트에 적용해 공부중인데 매우 합리적인 선택지라는 생각이 든다.

현직 개발자들은 대부분 현명하고, 최선의 선택을 하기위해 노력하는 만큼

Recoil이 사랑받는데는 분명히 이유가 있다.

(수정할 사항이 있다면 자유롭게 알려주세요. 저에게 큰 도움이 됩니다.)

나는 그동안 redux를 쓰며 의문을 가졌다.

사실 쓰기 매우 꺼려지기까지 했다.

global state 관리를 위해

redux를 쓰는것은 동의

다만, 그 많은 코드를 써가면서까지

비동기 요청을 하고

응답된 데이터를 state로 관리하고

해야되는걸까?

실제로 서비스를 개발하면서

gloal state로 관리해야될 데이터는

많지 않았던것같다.

때에 따라서는

global state로 관리되는 데이터들에대한

최신화 문제를 겪기도했다.

이번에 새로운 앱 MVP 제작을위해

자료조사를 하던도중

이 포스팅을 보고

"react-query" 를 도입해보았다.

react-query는 global state를

server-state와 client-state라는

두개의 개념으로 분리해서 바라본다.

나는 이에 크게 동의했다.

예를들어, 포스팅 목록을 불러왔을때는

글로벌로 관리해야한다고본다.

(사용자가 새로고침하기 전까지는)

대신, 포스팅 단일 데이터는

굳이 글로벌로 관리할 필요가 있을까?

아니라고 생각한다.

global state라는 개념을 도입하게된 배경은

[부모 -> 자식 -> 자식 ->  자식 -> 자식]

으로 props를 전달하는데 불편함이 있어서이며,

불필요한 fetch를 방지하기 위함이다.

포스팅 단일 데이터호출 및 렌더링에는

이런 문제가 있지도 않을텐대

그 많은 코드를 써가며 global state로

관리할 이유가 없다고 생각하는것이다.

이런 측면에서 접근했을때

경우에 따라 global state로 관리해야 하는 경우에만

Redux를 이용하고

일반적으로는 state 그 자체면 충분하다.

특히나, 비동기 요청을 위해

redux-sage, redux-thunk등을 쓸 이유?

는 없어진다고 생각한다.

아직까지는 대규모 프로젝트에서

관리의 용이성을 위해 redux + redux-saga를 많이 쓴다곤 하지만

react-query가 어느정도 궤도에 이르면

redux + react-query 구조로 가지는 않을까하고

조심스럽게 예상해본다.

이제 만들고있는 앱에

redux도 붙이러 가야겠다

redux-saga, redux-thunk가

너무나도 싫어서

기피하고 외면하던 게으른 개발자가

마음에 쏙드는 신문물을 발견해

작성한 포스팅입니다.

최신 자바스스크립트 개발환경은

3강체제이다

React, Vue, Angular

그중에서도 최강자 React를

운좋게도 처음시작부터 계속해서 쓰고있다.

근데 이게 너무나도 빨리

유행이 변해가다보니

따라가기가 정말 쉽지않다

자칫 쉬어가다간 바로 고인물이다.

유행을 따라가는게 좋은것만은 아니라고들 하지만

React의 변화는 단순한 유행이 아니다.

예를들어, 망치가 처음 만들어졌을떄

지금의 모습이 아니었을것이다

힘을 더 잘주기위해 손잡이가 길어졌을테고

너무 길어지니 과유불급이라 판단되어

적정 수준의 길이를 찾았을테고

쇠뭉탱이의 무게나 크기도

오랜 시간을 거쳐 발전했을것이다

React도 마찬가지인것같다

그중에서도  React의 핵심이라고 할수있는

state (상태)

에 대한 관리는 많은 이슈를 가지고있다

춘추전국시대가 끝이 보이질않는다

Context API

Redux

MobX

Context API의 진화

Recoil

...

...

각각이 가진 고유한 특성과

장단점들이 있다

내가 가진 얄팍한 지식으로 그것들을 설명하기보다는

써본 결과..

너무나도 불편하고 지저분하고

이렇게까지 해야되나? 

그냥 예전 바닐라 스크립트 시절이 더 날지도...

라는 생각과

사과하나 자르려고

사과 공장을 차리는 느낌이 자꾸만 들었다

그런와중에 내가 원하는

바로 그 라이브러리를 찾게되었다.

내가 원하는건 별게아니다

1. 글로벌 상태 관리

2. 지저분한 코드 x

3. 간편한 유지보수

이 3가지면 충분하다.

뭐 미들웨어로 어쩌니저쩌니

커스텀 훅으로 두들겨패니 뭐니

그런거는 기본기만 되어있으면

원하는 사람이 붙여쓰면 되는것 아닌가?

이런 나의 니즈를 충족시켜준

라이브러리는

react-query (+ axios)

react-query는 서버로 부터 받아온 정보를

(통칭 Server state)

정말 간단하게 글로벌 state로써 관리하고

재호출할수 있으며

로딩/실패/성공에 대한 진행상황(status)을

체크할 수 있다.

진짜, 간략한 샘플코드를 확인해본다.

// index.js
import React from 'react';
import App from './App';
import { QueryClientProvider, QueryClient } from 'react-query';
...

function main() {
  const queryClient = new QueryClient();
  
  return (
    <QueryClientProvider client={queryClient}>
      <App />
    </QueryClientProvider>
  )
}

...

// api.ts
import axios from 'axios';
import { useQuery } from 'react-query';

const getNameAPI = async () => {
  try {
    const { data } = axios.get('...');
    return data;
  } catch(error) {
    throw error;
  }
}

export const getName = () => {
  return useQuery('test/name', getNameAPI);
}

// App.tsx
import React, { useEffect } from 'react';
import { useQueryClient } from 'react-query';
import { getName } from './api';

function App() {
  const queryClient = useQueryClient();
  const { data, status, error, isLoading } = getName();
  console.log('fetching data 확인: ', data, status, error, isLoading);
  
  useEffect(() => {
    // 5초뒤에 이전에 호출했던 API에서 받아온 server state를 확인해본다.
    setTimeout(() => {
      const data = queryClient.getQueryData('test/name');
      console.log('data: ', data);
    }, 5000);
  }, []);
  
  return (
    <div>
      ...
    </div>
  )
}

어떤가?

아주 기본적인 방식으로 axios, fetch등을

이용해 데이터를 호출한뒤

useQuery에 key와 콜백함수만 등록해주면

queryClient를 이용해서

이전에 불러왔던 데이터를 확인할 수 있다.

redux를 쓸때의 코드양과 비교하면

이루 말할수없을정도로

행복한 코드라고 할수있다.

서버로 부터 불러온 데이터를 재가공할일이

많다던지 하는 경우에는

redux를 쓰라고 한다.

그건 그때가서 볼일이다.

웹/앱을 개발한지 얼마 안됐을때

그 프로젝트가 그 단계까지 갈지말지는

모르는법이다.

가볍게 시작해서

살을 더해가자

React 개발을 하다보면 전역적으로 상태관리를 해야할 때가 온다.

작은 시스템일수록 그럴일은 없지만,

시스템이 커질수록 쓸일이 생기기 마련이다.

그렇다고 프로젝트 초기부터, 이게 커질지 아닐지도 모르는데 Redux와 같은 상태관리 시스템을 도입하자니,

코드가 길어지고 상대적으로 개발시간이 다소 길어지는 것을 감수할 필요는 없다는 생각이 든다..

이 때, 딱 적당한것이 Context API인것같다.

처음부터 세팅해두고 시작할필요없이 (프로젝트 구조와 거의 무관하게) 쉽게 적용하여 쓸 수 있다.

이미 짜둔 코드에 몇줄 얹으면 끝이다.

시작에 앞서, context가 무엇인지 설명하자면 Consumer와 Provider를 통해 글로벌하게 state를 관리하는 도구이다.

이게 무슨말이냐면, 아주 유용한 연필을 하나 만들어두고 누구든 원하면 쓸수있게 Provider를 통해 연필을 전체적으로 공급한다.

그리고, 누구든 연필이 필요한 녀석(component)은 Consumer를 통해 그 연필을 가져다 쓸수있다는 말이다.

코드의 중복이나 상속의 상속의 상속...같은 낭비를 하지않을수 있으니 매우 유용하다고 볼수있다.

그러면 가장 기본적인 사용법을 알아본다.

import React, { creatContext } from 'react';

const { Provider, Consumer } = createContext();

class ItemProvider extends React.Component {
	state = {
    	item: null,
    }
    
    actions = {
    	onClear: () => {
        	this.setState({ item: null });
        },
        onGotTool: (tool) => {
        	this.setState({ item: tool })
        }
    }
    
	render() {
	    const { state, actions } = this;
        const value = { state, actions };
    	return(
        	<Provider value={ value }>
            	{ this.props.children }
            </Provider>
        )
    }
}

const ShowItem = () => (
	<Consumer>
    {
    	({ state, actions }) => (
        	<div>
            	<div>
                	<span>나의 도구: </span>
	                { state.item }
                </div>
				<div>
                	<p onClick={() => { actions.onGotItem('Hammer'); }}>도구 획득</p>
                </div>
            </div>
        )
    }
    </Consumer>
)

class App extends React.Component {
	render() {
    	return (
        	<ItemProvider>
            	<div><ShowItem /></div>
            </ItemProvider>
        )
    }
}

React에서 Redux를 함께 쓰다보면, 혹은 React를 사용하다보면

불변성과 관련하여 종종 맡닥드리는 문제상황들이 있다.

불변성 관리의 편리함을 제공해주는 immer, immutablejs 등이 있는데,

그것들을 사용하더라도 javascript에 대한 이해도가 떨어지면 결국 문제상황과 만나게된다..

특히, array..object..array.. array..와 같은 깊은 구조에서 문제가 발생한다.

이때, 한가지만 명심하면 해답을 찾을 수 있다.

"값을 직접 바꾸지 마라" 라는 react의 철학이다.

위와같이 깊고 복잡한 구조에서는 arr['something']['action']['whatIndex'] = value;

와 같이 값을 직접 변경할것이 아니라

splice등과 같은 array method를 이용하도록 하자.

웹사이트 개발 / 홈페이지 제작 / android앱 개발 / ios 앱 개발 / server / client / aws / fullstack / buisness partner / 외주 / 용역

https://open.kakao.com/o/sNETgUJb

http://self-made.cloud

react / redux 환경에서 처음 개발하다보면 당황스러운 경험을 하게된다.

state에 값을 담기위해 onChange에서 setState 할때마다, 

re-rendering되면 input에서 focusout되는 것이다.

도저히 값을 입력할수가없다.

상황은 매우 난감하지만 해결방법은 매우 간단하다.

해당 input이 속한 컴포넌트 wrapper에(제일 바깥 껍데기) key를 주는것이다.

웹사이트 개발 / 홈페이지 제작 / android앱 개발 / ios 앱 개발 / server / client / aws / fullstack / buisness partner / 외주 / 용역

https://open.kakao.com/o/sNETgUJb

http://self-made.cloud

[redux]

최신 웹 기술들을 접하는걸 즐기는 사람이라면 누구나 한번쯤은 들어봤을 법한 라이브러리다.

도대체 redux란 무엇일까? 사람들이 왜 redux에 열광하는 것일까?

난 react가 정말 완벽하다고 생각하고 사용하고 있었으며, redux는 불필요한 것으로 치부하고 배우지 않고있었다.

사실은 도망친 것일수도 있다.

왜 이렇게 배울게많은거야? 또 새로운 거야? 하고말이다.

(이미 나온지 한참됐지만)

그치만 최근 개발하여 론칭한 대규모의 앱인  '공무원 시험일정, 공시생 SNS: 공투공' 을 만들며 그 필요성을 절실히 느끼고 익히게 되었다.

아니, 익히고 있는 중이다.

경험을 바탕으로 말하자면, 정말 작은 프로젝트에서까지 redux를 적용할 필요는 없을것 같다

(경우에 따라서는 필요할수도)

하지만, 규모가 커질것으로 예상되거나 큰 규모의 프로젝트를 계획하고있다면 redux는 확실히 도입해볼법한 라이브러리다.

그렇다면 도대체 redux란 무엇인가?

간단히 검색해보면 알수있듯 상태 관리 라이브러리다.

상태 관리란 무슨 의미일까?

프로젝트 내에는 다양한 오브젝트들이 있는데 그 안의 변수, 메서드 등의 현재값을 상태라고 본다.

그렇다면 상태를 관리한다는 것은 무슨 의미일까?

프로그램 내에는 다양한 범위(전역, 지역, 지역의 지역...)의 변수, 메스드 등이 존재한다.

이런 상황에서 특정영역A의 변수값a, 특정영역B의 변수값 b가 있을 때, b의 변화에따라 a의 값을 바꿀수 있겠는가?

생각해 본적 있는가? 있을것이다. 물론 없을수도 있다. 지금 생각해보면 된다.

잠시만 생각해보면 전역으로 모든 값을 관리하면 가능하다는 결론을 도출할 수 있다.

이런 생각에 기반해서 등장한 것이 상태관리 라이브러리다.

유용하고 유명한 상태관리 라이브러리로는 redux, mobx등이 있다.

이 중에서 redux를 알아볼 것이다. 얕지만 누구나 이해할 수 있는 수준에서.

redux를 사용함에 있어 알아둬야할 사항을 먼저 얘기하고 시작한다.

1. redux는 라이브리리이다. 따라서, react와 함께는 물론 어느 환경에서도 유연하게 적용할 수 있다.

2. redux의 등장배경을 떠올려보면 당연한 이야기이지만, 프로젝트 내에는 단 하나의 'store'만이 존재한다.

3. '상태'는 immutable하다. 겁먹을 필요없다. 그저 '읽기전용' 이라고 생각하면 된다. 상태에 대하여 직접 입력, 수정 등을 행하지 않는다.

4. 앞으로 알게될 'reducer'는 '이전의 상태'는 건드리지 않고 '다음의 상태'값만을 생성해서 반환한다.(순수한 함수)

이제, 다음 글에서 본격적으로 redux를 어떻게, 어떤 구조를 이루어 써야하는지 알아본다.