1/6[TIL]React(3)

프론트엔드 개발에서의 Side Effect?

상태를 다룰 때에 Side Effect는 주요 고려대상이다.

함수의 입력 외에도 함수의 결과에 영향을 미치는 요인으로 대표적으로 네트워크 요청, API 호출이 Side Effect의 예로 볼 수 있다.

우리는 컴포넌트를 만들 때 Side Effect를 최대한 배제하고 컴포넌트를 만들어야 한다.

쉽게 말해 위의 예로 들었던 네트워크 요청이나 API 호출 이 없어도 하드코딩 데이터 만으로도 작동이 가능해야 하다는 것이다.

하지만 앱을 만들다 보면 분명 API 호출도 해야 하고, side effect는 불가피하게 생기기 마련이다. 장바구니에 데이터가 서버에 있다면 네트워크 요청(fetch) 때문에 오래 걸릴 수도 있다.

데이터 로딩 여부 (isLoading) 라는 상태가 true

이럴 때에는 "로딩 중"을 표시하여 해결 할 수도 있다. 이러한 여부는 데이터 전송 여부에 따라 달려 있다. 앱을 만들고, UI를 구성할 때에는 항상 이러한 로딩 중 상태도 고려하여야 한다.

상태를 로컬(특정 컴포넌트 안에서만 관리) / 전역(프로덕트 전체 혹은 여러 컴포넌트에서 관리) 두 가지로 구분할 수도 있는데

서로 다른 컴포넌트가 사용하는 상태의 종류가 다르면, 꼭 전역 상태일 필요는 없으나

특히 전역적인 측면에서 본다면

서로 다른 컴포넌트가 동일한 상태를 다룬다면, 이 출처는 오직 한 곳이어야 한다.

이 것은 데이터 무결성이라는 말과 이어지게 된다.

전역 상태의 예로는 웹사이트의 다크 모드 기능, 국제화(언어) 설정, 포토샵/일러 의 히스토리 기능으로 들 수 있다.

앞서 쭉 언급한 상태 관리를 도와주는 각종 툴 들이 존재한다.

React Context / Redux / Mobx...

쉽게 말해 전역 상태 저장소를 제공하는 것이다.

그리고 props drilling 이슈를 해결해 준다.

SPA

페이지를 전환하지 않고 ajax를 통해서 정보를 필요한 부분만 업데이트한다.

Client side Routing

url이 바뀌고 동시에 앱 상태가 바뀌고 있는 것