[TIL] 2022-11-30

H Kim·2022년 11월 30일
0

TIL

목록 보기
32/72
post-thumbnail

오늘 처음으로 리뷰 했다!
그 과정에서 알게 된 것들 정리.


??||의 차이

  • ?? : null 또는 undefined 일 시, 뒤의 값을 사용

  • || : 0 또는 '' 또는 null 또는 undefiend 일 시, 뒤의 값을 사용(즉, 모든 예외처리)

// null & undefined 를 처리
 <div>{data?.transfer?.transferInfo.transferAmt ?? 0}원</div>

// null & undefined & 0 & '' 를 처리
 <div>{data?.transfer?.transferInfo.transferAmt || 0}원</div>

사용자정의 hook

사용자 정의 hook을 만들기 위해서는 무조건 use로 시작해야 한다.
아니면 리액트가 사용자 정의 hook을 만든 건지 아닌지 구분을 못 해서 동작하지 않는다고 한다.
나는 그냥 useState setState처럼 관용적으로 그렇게 쓰는 거라고 생각했는데 이 경우에는 그게 아니고 아예 돌아가지도 않는다고 한다.


image require().default로 가져오지 말기

우리 프로그램에서는 이미 ../assets/images를 절대경로로 가져올 수 있게 처리를 해 놨기 때문에 images로 가져오면 된다고 한다. 나는 어쩐지 상대경로 from 으로 가져올 수가 없어서 찾고 찾다가 require().default로 가져온 거였는데 이거는 import랑 충돌날 가능성이 있어서 혼용해서 쓰면 좋지 않다고 한다.

또한 이 방법이 이미지가 뜨지 않을 때 최후의 방법(즉, 이 방법으로 가져오면 안 뜰리가 없다)으로 제시되는 이유는, import가 비동기적으로 라이브러리나 이미지를 가져오는 것과는 달리require는 ()안에 있는 것을 동기적으로 가져오게 된다. 지금은 이미지니까 별로 문제가 되지 않아서 괜찮다고 생각되지만 만약 라이브러리를 가져오거나 했을 때, webpack의 Tree Shaking(JS 모듈을 번들링 할 때 사용하지 않는 코드를 제거하는 최적화 과정)을 할 때 사라지지 않아 프로그램이 무거워지는 결과를 초래한다.


React.FC 사용하지 않아도 됨

const ComponentName: React.FC = () => {} 으로 되어 있는 부분에서 React.FC 부분을 굳이 쓰지 않아도 된다는 것이었다. 예전에는 이렇게 쓰면 리액트가 자동적으로 children 속성을 만들어줘서 따로 만들어주지 않아도 생겨서 편하니까 이렇게 쓴 거였는데 지금의 리액트 버전에서는 따로 만들어주는 동작이 모두 사라졌고, children 속성을 쓰려면 인터페이스로 선언해주어야 쓸 수 있기 때문에 이제는 쓰지 않아도 된다. 이렇게 써야 하는 때는 이 함수 자체를 모듈 형식으로 내보낼 때인데 이 때에는 필요하면 쓰게 되는 거니까 그 전까지는 없는 상태로 작업하는 것이 맞다고 한다.

그리고 솔직히 "모듈 형식으로 내보내는 것"이... 무슨 소리인지 이해할 수 없기 때문에^^


flushSync 관련

이번에 작업한 페이지가 복사붙여넣기 아티스트로서 활동하여 있던 코드를 복붙한 곳이 굉장히 많았는데^^
이러다가 중간에 flushSync 붙은 코드를 가져오면서 이게 뭔지 찾아봤었다. 나는 당연히 필요하니까 있는 거라고 생각해서 건드리지 않은 채로 계속 작업했는데 리뷰하면서 이 부분이 필요하냐는 거였다. 나는 모르니까 "저는 그냥 가져왔습니다...^^;;;" 했더니 이걸 넣어놓았던 부분은 예전에 리액터 18버전 이전에서는 함수 안에 들어가 있는 setState 함수들이 순서대로 셋팅이 돼서 이걸 한 번에 셋팅 시킬려고 넣어놓았던 건데 이제는 버전이 올라가서 이럴 필요 없이 자동적으로 한 번에 셋팅이 되기 때문에 필요가 없어졌다고 했다.

그렇다고 flushSync 자체가 필요없어진 건 아니고 오히려 차례대로 셋팅되어야 하는 쪽에서는 또 이걸 이용해서 조절을 할 수 있다고 한다. 어쨌든 지금 당장 나의 코드에서는 필요없어서 지우게 되었다.


Component와 Container의 차이

Component는 넘어오는 props로만 그리는 것이고 API 조회를 하거나 context API, 또는 상태관리(redux 등등)이 끼어들면 Container이다.

만들 때 이 페이지 안에 있는 부분들을 컴포넌트화 시키면 다른 페이지에서 재사용 할 가능성이 있을지를 생각한 다음에 가능성이 있을 것 같으면 컴포넌트화 시켜서 만드는 것이 좋다.

그리고 이것을 구분하는 게 주요한 이유는 이 것이 컴포넌트 폴더에 들어있냐 컨테이너 폴더에 들어있냐에 따라 나중에 혹시 이 부분을 활용해야 할 때 분리작업이 얼마나 걸릴지도 예상이 가능해진다는 장점이 존재한다. 컴포넌트일 경우에는 내려주는 props 데이터만 바꿔주면 활용할 수 있으니까 시간이 많이 걸리지 않을테고, 컨테이너일 경우는 연관되는 데이터를 모두 분리한 뒤 약간은 다시 만들어야 할테니 컴포넌트에 비해서는 시간이 더 걸릴 것이라는 추론이 가능해진다.

0개의 댓글