Side Effect in Frontend-Development

• 함수(or Component)의 입력 외에도 함수의 결과에 영향을 미치는 요인
  • 네트워크 요청 (backend API request)

• 상태를 다룰 때 주요 고려대상이다.

• 불가피한 Side Effect와 상태
  • 장바구니 데이터가 서버에 있다면, 네트워크 요청 때문에 지연될 수 있다.
    • 이러한 side effect에 의존적인 상태도 있을 것이다.

presentation Component

• 어떤 데이터가 들어오던지 심지어 가짜 데이터라 할지라도 컴포넌트는 표현 그 자체에 집중하는 것.

상태의 두 가지 구분

• 로컬
  • 특정 컴포넌트 안에서만 관리되는 상태
  • 다른 컴포넌트와 데이터를 공유하지 않는 form data (input box, select box)
    • 원래 가격 * 상태 => 컴포넌트 내에 표시되는 주문 금액 업데이트
• 전역
  • 프로덕트 전체 혹은 여러 컴포넌트에서 관리되는 상태
  • 다른 컴포넌트와 상태를 공유하고 영향을 끼치는 상태
    • 장바구니에 담긴 물품의 경우, 상품 선택여부에 따라 총 주문 금액을 업데이트
    • 장바구니에 담긴 물품은 그 갯수를 다른 컴포넌트에 전달
    • 데이터 로딩 여부 상태 역시 영향을 끼친다.

각 컴포넌트가 따로따로 상태를 갖고 있어도 되는가?

JS에서 배울 때 전역변수를 남용하는 것은 좋지 않다고 했다. 하지만 경우에 따라서 전역 상태가 필요하다. 서로 다른 컴포넌트가 사용하는 상태가 다르다면, 무조건 전역 상태이지 않아도 된다. 출처가 달라도 된다.
그러나, 서로 다른 컴포넌트가 동일한 상태를 다루는 경우에는, 출처(전역공간)는 같아야 한다. 만일 사본이 있을 경우 두 데이터는 서로 동기화하는 과정이 필요하기 때문이다. 그래서 한 곳에서만 상태를 저장하고 접근하는게 좋다.

전역 상태에서의 데이터 무결성

• 데이터의 정확성을 보장하기 위해 데이터의 변경이나 수정 시 제한을 두어 안정성을 저해하는 요소를 막고 데이터 상태들을 항상 옳게 유지하는 것
  • Single source of truth
    • 동일한 데이터는 항상 같은 곳에서 데이터를 가져온다.(신뢰할 수있는 단일출처)
• 데이터가 존재하고, 데이터를 보여줘야하는 frontend에서는 철저하게 우리가 의도한대로 예외 상황없이 데이터를 잘 보여줘야 한다.
• 보여주고자 하는 데이터가 있다면, 어떤 경우에도 UI 상에 잘못 전달되는 일이 없게하자.

전역 상태 관리 Case Study

라이트 모드/ 다크 모드 테마 설정

• 전역으로 상태를 관리하는 경우는?
  • 모든 컴포넌트에 다크모드 or 라이트 모드가 적용이 되어야하기 때문에 이러한 테마 설정을 전역으로 관리할 수 있다.

국제화 설정

• 사용자가 사용하는 브라우저나, 운영체제가 특정 언어를 사용하고 있음을 알아내서, UI에 필요한 텍스트 리소스를 따로 저장한 후, 전역 상태로 관리한다.
  • 이 기능 또한 모든 컴포넌트에서 사용자 언어로 표현이 되어야 하기 때문에, 전역에서 상태 관리가 필요하다.

상태 관리를 위한 TOOLS

• React Context
• Redux
• MobX

TOOls는 어떤 문제를 해결해주는가?

• 전역 상태 저장소 제공
• Props drilling 이슈 해결

하지만 상태 관리 툴이 반드시 필요한 것은 아니다.

• React 공식문서의 React 사고하기만 잘 따라와도 대부분의 문제는 해결할 수 있다.