원티드 프론트엔드 프리온보딩 : React [2주차]

import { startTransition } from 'react';

// 긴급한 업데이트 : 입력하고 있는 값
setInputValue(input);

// startTransition으로 래핑된 업데이트는 긴급하지 않은 것으로 처리되고, 더 긴급한 업데이트가 들어오면 중단된다.
startTransition(() => {
  // 전환 업데이트: 입력값에 따른 쿼리값
  setSearchQuery(input);
});

2주차 주제

🛠️ 상태 관리가 rendering에 미치는 영향🛠️ 

리액트 훅에대한 자세한 설명은 이전에 다뤘으므로, 간단하게 비교 및 언제사용하면 좋은지에 대해서만 다루겠다.

---

useState vs useReducer

---

useState

간단한 상태관리

• 값이 하나인 경우
• 상태들이 서로 관련이 없는경우

컴포턴트 내에서 사용

prev를 사용해야한다(렌더링이 되지않아도 현재 값을 받아온다)

• 함수내에서 setState를 통해 상태를 변경해도, 함수가 종료되고 리렌더링 되기전까지는 상태값은 그대로기 때문에 같은 함수내에서 state값을 다루려면 prev를 권장한다.

유즈 이펙트안에 셋 스테이트를 사용하는건 좀 위험하다

함수형 프로그래밍에 유의하면서 사용해야한다.

---

useReduser

복잡한 상태관리

• 상태들이 서로 관련이 있거나, 참조가 필요한 경우(ex. isSignup 이란 state 값이 true로 변하면 isLogin이라는 state는 false로 변경하면서 로그인화면에서 회원가입화면으로 가야한다. )

여러 컴포넌트에서 상태가 공유되어야함

• ContextAPI(useContext) 사용 시 사용하는 것이 일반적

reducer를 따로 선언하는것이 일반적

스케일이 큰 프로젝트의 경우 선호됨.

불변성(순수함수)

---

🌟 컴포넌트 최적화 🌟

블로그에서 읽은 내용을 추가하면, useReducer는 state 업데이트 로직을 분리하여 컴포넌트의 외부에 작성하는 것을 가능하게 함으로써, 코드의 최적화를 이루게 해준다.

이 설명을 읽고 useState와 useReducer의 코드를 다시 보니 다음과 같은 차이가 있었다.

• useState는 상태 변경 로직을 컴포넌트 내에 포함하고 있다. 버튼 내부의 함수 내용을 handleIncrement와 같은 별도의 함수로 분리한다 하더라도 상태 변경 로직은 여전히 해당 컴포넌트 내에 속하게 된다.
• useReducer는 우선 해당 컴포넌트로부터 완벽히 분리 가능한 reducer 함수를 사용한다. 또한 dispatch를 통해 어떤 변경을 일으킬지만 알려주고(type), 상태 변경 로직은 오롯이 reducer 함수에게 맡긴다. 즉, 컴포넌트는 철저히 뷰를 렌더링 또는 (상태 변경 후) 리렌더링하는 역할만 맡게 된다.

앞으로 이러한 컴포넌트 최적화를 위해서라도 useReducer를 많이 활용해야겠다는 생각이 들었다. 인프콘의 준프 연사님이 강조하신 뷰 로직과 비즈니스 로직의 분리도 이와 비슷한 개념인 것 같다.

---

useMemo

함수의 "결과"를 캐싱할때 사용한다.

초기렌더링보다는 캐싱되는것을 고려할 때 리렌더링에 유리하다.()

어지간하면 안써도된다.

정말 써야되는 근거를 가지고 사용하는게 좋다.

• “Expensive” computation
• React는 1ms이상 걸리면 "Expensive"라고 칭한다.
• “Expensive”하지 않다면 굳이 필요 없다.

---

useCallback

"함수자체"를 캐싱하기위해 사용한다

차일드 컴포넌트로 프랍을 넘겨 줄 때 사용권장

부모컴포넌트의 값을 자식컴포넌트가 바꿔주는걸 지양해야한다

• 예를들면 setState를 자식에게 넘기고 자식이 setState를 사용하여 state값을 변경

---

🛠️ React 18에 새롭게 등장한 hook🛠️ 

useId

유니크한 아이디값 만들 때 만든다.

단, list의 key를 만들어주기 위한 훅이 아니니 그렇게 사용하지 말자.

추상화에 유리하다

그치만 굳이? 써야하나?

내장형 uuid느낌?

 

startTransiton/ussTranstion

useTransition과 startTransition은 일부 상태 업데이트를 급하지 않은 업데이트로 간주한다. concurrent에서는 급한 상태 업데이트가 급하지 않은 상태 업데이트를 중단할 수 있다..

• 긴급한 업데이트 (urgent updates) : 입력, 클릭, 누르기 같은 다이렉트 상호작용을 반영
• 전환 업데이트 (transition updates) : UI의 전환

타이핑, 클릭, 누르기 같은 긴급 업데이트는 빠르게 업데이트 되지 않으면 버벅거리면서 앱이 이상하다는 느낌을 줄 수 있다. 하지만 화면은 곧바로 결과값을 볼거라고 기대하지 않기 때문에 전환 업데이트는 느리게 업데이트가 되어도 괜찮다.

 

 

import { startTransition } from 'react';

// 긴급한 업데이트 : 입력하고 있는 값
setInputValue(input);

// startTransition으로 래핑된 업데이트는 긴급하지 않은 것으로 처리되고, 더 긴급한 업데이트가 들어오면 중단된다.
startTransition(() => {
  // 전환 업데이트: 입력값에 따른 쿼리값
  setSearchQuery(input);
});

 

useSyncExternalStore

라이브러리 개발을 위해 제공된 훅이다. (CSS-in-JS)

• 스타일드 컴포넌트와 같은 CSS in JS 개발하는 개발자아니면 쓸 일이 있을까 싶다.

---

🛠️상태관리 라이브러리🛠️ 

 

Redux

 

상태관리 라이브러리 1황 리덕스.

스토어하나에 모든상태를 저장한다.

Context API가 Context별로 reducer를 따로 사용하는 것과 반대됨.

 

Recoil

 

리액트와 가장 호환이 잘되는 상태관리 라이브러리(made by meta)

아톰과 셀렉터라는 개념을 사용
내가 필요한 값만 구독한다
아톰은 일반적인 스테이트와 유사한개념
구조가 간단해서 적용하기 쉬움
리액트 관리를위해서 만들었다.
훅과 비슷하게 쓴다 그래서 편하다!

 

zustand 

 

리덕스의 후계자
리덕스 개발자도구도 사용 가능하다

---

기타 질문에 대해 답변해주신 것

 

프론트엔드 엔지니어가 CI/CD에대해 깊은 이해가 필요할까요?  => 배포빌드는 깃헙액션만으로 충분하다

기능구현은 잘 하는데 CSS가 약해요 괜찮을까요? =>프론트는 디자이너 잘 만나는게 중요하다

웹팩을 커스텀하는 과정이 너무귀찮은데 나중에 문제가 될까요? => 바이트나 spa로 한다. 웹팩? 설정고민하지마라

리덕스 쓰는데, 스토어에 개인정보 넣어도 되나요? => 스토어에 개인정보 넣으면 큰일난다.