today i worked 5/18: Next.js 내 다른 페이지에서 같은 Context를 공유하는 방법

8-16(1시간 시차) 사무실 출근

1. sales registration을 넣으려고 하는데.. 상품정보제공고시 부분 Context를 해결해야 한다.

2. 자꾸 useQuery를 사용했을 때 data에 값이 들어가는 속도보다 그 data를 가공하는 코드가 더 빨리 실행된다는 문제가 생긴다. data를 가공하는 코드가 실행되었을 때는 data에 useQuery의 값이 반영되어있지 않으므로 undefined 에러가 발생하게 된다. useMemo나 useEffect를 사용해보기도 했는데 일단 계속 고민해봐야겠다.

3. 일단 작업할 수 있는 다른 파트 마크업 먼저 완성해두기.. 다음주 주말까지 해야 할 일이 너무 많다 ㅜ

 

Next.js에서 예를 들어 http://localhost:3000/3289493241/sellable 이런 형태의 URL을 사용한다고 했을 때 sellable은 3289493241(시리얼 넘버)에서 nested 처리가 되어있는 것이 아니다. 단지 다이나믹 라우팅만 되어있을 뿐.. 그래서 serialNumber 페이지에서 Context를 적용해줘도 sellable 페이지에서 이 Context가 적용이 되어있지 않고, 적용하려면 다시 선언을 해줘야 하는데 이 경우라면 serialNumber 페이지에서 적용한 Context와 sellable 페이지에서 적용한 Context는 껍데기만 같을 뿐 안에 저장된 데이터는 다르다. 정확히는 serialNumber 페이지에서 dispatch로 값을 저장해줬다 한들 sellable 페이지로 이동한다면 데이터가 비어있는 것이다. 왜냐면 같은 Context를 사용할 뿐이지 실제로 그 Context가 적용되는 위치 자체가 다르기 때문이다.

 

헌데 내가 해야 했던 건 serialNumber에 적용한 Context의 데이터 그대로를 sellable 페이지에서 적용하는 것이었다. 즉 같은 Context를 쉐어하는 것이다. 고민해 본 결과 방법이 네 가지가 있었다.

 

1) 리덕스 사용(reduxjs-toolkit)

  - 컨벤션에 맞지 않아 폐기. 우리는 Context API만을 사용하기로 했다.

2) 모든 페이지들을 감싼 최상단 _app.tsx에 Context Provider를 적용해주기

  - 이 Context가 다른 곳에서도 많이 쓰이며, 그 때마다 같은 Context가 쉐어되어야 할 경우에는 매우 유용하며 가장 쉬운 해결책이다. 그러나 현재로서는 serialNumber와 sellable에서만 사용할 예정이므로 좋은 해결책으로 보이지는 않는다. 이렇게 _app.tsx에 Context들을 밀어넣는 건 추후에 가독성도 해칠 뿐더러 불필요하게 Context가 유지되는 현상이 생긴다고 생각한다.

3) Custom Hook을 사용해서 그 Hook 안에 필요한 데이터를 넣기

  - 리덕스와 비슷한 느낌으로 가는 건데 이렇게 쓸 거면 그냥 리덕스를 쓰는 게 낫지 않을까 싶긴 하다.

4) EntryPointUsingXXXProvider와 같은 컴포넌트를 만들고, props로 어떤 페이지인지 지정해 준 다음 이 컴포넌트의 return을 쉐어하면서 사용할 Context Provider로 덮는다. 그리고 prop Type에 따라 serialNumber 혹은 sellable을 렌더링한다.

  - 컴포넌트의 네이밍만 잘 된다면 가장 좋은 해결책이라고 생각한다. 

 

우선은 다른 해야 될 부분이 급해 임시방편으로 _app.tsx에 감싸뒀으나 이후에 좀 여유가 생긴다면 4번의 방식으로 리팩토링할 예정이다.

 

여담으로 요새 맨날 뉴발란스 993 그레이가 눈에 밟혀서 크림을 들락날락 거렸는데.. 나는 산지 7-8년 정도 됐지만 얼마 안 신은 993 블랙을 갖고 있다. 오늘 회사에 신고와서 보니 굳이 27만원이나 주고 색상만 다른 같은 신발을 사는 건 낭비라고 생각해서 참기로 했다,, 이거로 그냥 내 방이나 꾸며야지,,

 

개발용어

nit: nitpick의 줄임말로, 하찮은 일로 트집잡는다는 뜻.

코드리뷰에서 많이 쓰며 코드 자체에 대한 얘기보다는 변수명이나 코드 스타일 등을 지적할 때 사용함.

ex) GET API를 해오는 과정에서 response의 return값의 타입 명을 EachProductType으로 지정한 상황에 대한 리뷰