[React] "리액트를 다루는 기술" 15장-18장 키워드

Context API

환경 설정, 사용자 정보와 같은 전역적으로 필요한 상태를 관리해야할 때 사용

리덕스나 MobX 같은 상태 라이브러리를 사용하여 전역 상태 관리 작업을 더 편하게 처리하기도 하지만, 리액트 v16.3 업데이트 이후 Context API가 많이 개선되어 별도의 라이브러리를 사용하지 않아도 전역 상태 관리 가능

리액트 공식 문서: https://ko.reactjs.org/docs/context.html

Context – React

context를 이용하면 단계마다 일일이 props를 넘겨주지 않고도 컴포넌트 트리 전체에 데이터 제공 가능

context API를 사용하기전 주의할점

Context는 꼭 용도에 맞는 상황에서만 사용해야한다. 즉, 전역 데이터를 한 곳에서 저장하고 여러 컴포넌트에서 접근하고 싶은 경우가 아니라면 사용을 안하는게 좋다. 문서에 따르면 Context 를 사용하게 되면 해당 컴포넌트는 해당 Context가 없이는 재사용이 어려워지므로 꼭 필요 할때만 사용해야한다.

 

Context는 "컴포넌트 재사용을 어렵게 만든다"라는 말을 통해 최대한 사용을 줄이는 것을 권장한다는 의미이다. 앱의 상태를 context로 관리할 수 있지만, redux나 다른 상태 관리 라이브러리들이 이런한 목적으로 만들어진데 반해, context는 그런 목적으로 설계된 것이 아니다.

context는 단지 react 앱을 새롭고 더 나은 방법으로 정돈할 수 있을 뿐이며, Redux 같은 상태 관리 라이브러리를 사용한다면 더 쉽게 connect된 컴포넌트를 작성할 수 있다.

 

또한 Context API가 아무리 글로벌 상태 관리를 쉽게 관리한다고 해도, 이미 리덕스나 Mobx를 사용하고 있는 프로젝트들이 무수히 많고 추가적으로 리덕스에서 제공하는 미들웨어 같은 강력한 기능을 Context API에서는 제공할 수 없기 때문에 Context API는 redux와 같은 생타 관리 라이브러리를 서로 경쟁적인 기술로 볼 필요가 없다.

Redux의 강점

1. 사용자가 어떤 액션을 하고, 어떤 데이터가 변경 되었는지 쉽게 관찰할 수 있고, 기록된다.

  또한, 개발자가 원하는 이전 특정 상태로 돌아가볼 수 있다.

2. 무수히 많은 사용자들이 동시에 접속하는 페이스북, 인스타그램 같은 서비스에서 큰 힘들 발휘한다.

3. Redux 자체에서는 비동기 작업들을 도와주는 도구들을 지원한다. 대표적으로 많이들 쓰는 redux-thunk는 비동기 작업을 사용할 때 가장 기본적이고 편리한 방법이다.

4. 컴포넌트의 상태 업데이트 관련 로직을 다른파일로 분리시켜서 더욱 효율적으로 관리할 수 있다.

  코드를 유지보수하는 데 도움이 된다.
  또한, 컴포넌트끼리 똑같은 상태를 공유해야할 때도 여러 컴포넌트를 거치지 않고 손쉽게 상태 값을 전달하거나 업데이트 할 수 있다.

  실제 업데이트가 필요한 컴포넌트만 리렌더링이 되도록 쉽게 최적화해 줄 수 있다.

5. 단순히 전역 상태 관리만 한다면 Context API를 사용하는 것만으로도 충분하다. 하지만 리덕스를 사용한면 상태를 더욱 체계적으로 관리할 수 있기 때문에 규모가 클 경우에는 리덕스를 사용하는 편이 좋다.
   코드의 유지 보수성을 높여주고 작업 효율을 극대화 해주기 때문

Redux의 세 가지 규칙

1. 단일 스토어

  하나의 애플리케이션 안에는 하나의 스토어가 존재한다(복수개의 스토어 사용이 가능하나 권장하지 않음)

2. 읽기 전용 상태

  리덕스 상태는 읽기 전용이다. 불변성을 지켜주기 위해 spread 연산자 또는 immer와 같은 불변성 관리 라이브러리를 통해 상태를 업데이트 할 때 기존의 객체는 건드리지 않고 새로운 객체를 생성해 주어야 한다.

  리덕스가 불변성을 유지해야하는 이유는 내부적으로 데이터가 변경되는 것을 감지하고 얕은 비교(shallow equality)검사를 하기 때문

 객체의 변화를 감지할 때 객체의 깊숙한 안쪽까지 비교하는 것이 아니라 겉핥기 식으로 비교하여 좋은 성능을 유지할 수 있다.

3. 리듀서는 순수한 함수

  리듀서 함수는 순수한 함수여야 한다.

  순수한 함수란

   - 리듀서 함수는 이전 상태와 액션 객체를 파라미터로 받는다.

   - 파라미터 외의 값에는 의존하면 안된다.

   - 이전 상태는 절대로 건들지 않고, 변호를 준 새로운 상태 객체를 만들어서 반환.

   - 똑같은 파라미터로 호출된 리듀서 함수는 언제나 똑같은 결과 값을 반환

 * 리듀서 함수 내부에서 랜덤 값을 만들거나, Date 함수를 사용하여 현재 시간을 가져오거나, 네트워크 요청을 한다면, 파라미터가 같아도 다른 결과를 만들 수 있기 때문에 절대로 사용해선 안된다.

Redux Middleware

액션을 디스패치했을 때 리듀서에서 이를 처리하기에 앞서 사전에 지정된 작업을을 실행하게 하며, 액션과 리듀서 사이의 중간자라고 할 수 있다.

미들웨어는 결국 함수를 반환하는 함수를 의미

리덕스 미들웨어가 필요한 이유

기존의 리덕스는 액션이 발생하게 되면, 디스패치를 통해 스토어에게 상태 변화의 필요성을 알리게 된다. 하지만, 디스패치된 액션을 스토어로 전달하기 전에 처리하고 싶은 작업이 있을 수 있을 수 있다. 가령, 단순히 어떤 액션이 발생했는지 로그를 남길 수도 있겠고, 액션을 취소해버리거나, 또 다른 액션을 발생시킬 수도 있다.

 

우리가 알고 있는 리덕스는 동기적인 흐름을 통해 동작한다. 액션 객체가 생성되고, 디스패치가 액션 발생을 스토어에게 알리면, 리듀서는 정해진 로직에 의해 액션을 처리한 후 새로운 상태값을 반환하는 과정이다. 하지만, 동기적인 흐름만으로는 처리하기 힘든 작업들이 있다. 가령, 시간을 딜레이시켜 동작하게 한다던지, 외부 데이터를 요청하여 그에 따른 응답을 화면에 보여주어야 하는 등.

 

리덕스에서는 이러한 비동기 작업을 처리하기 위한 지침을 알려주지 않고 있기 때문에 이러한 비동기 작업을 처리하는 데 있어 리덕스 미들웨어를 주로 사용한다.

 

• redux-thunk : 리덕스 창시자인 댄 아브라모프가 만든 가장 많이 사용되는 비동기 작업 미들웨어로, 액션 생성 함수에서 일반 액션 객체를 반환하는 대신 함수를 반환.
• redux-saga : 전자 다음으로 가장 많이 사용되는 비동기 작업 미들웨어 라이브러리로, 특정 액션이 디스패치되었을 때 정해진 로직에 따라 다른 액션을 디스패치시키는 규칙을 작성하여 비동기 작업을 처리할 수 있게 해준다.