
[작년 초 라이트하우스로 성능을 개선](https://haeun.vercel.app/blog/2204-lighthouse)했었는데요!
그 이후로 여러 기능을 추가하고 리팩토링을 했어서, 다시 한번 라이트하우스 점수를 체크해보았습니다.

## 개선 전 총점

<img alt='라이트하우스 총점' src='/images/blog/23/lighthouseTotal.png' width='450px'/>

개선 전에는 성능 77점, 접근성 100점, Best Practices 100점, 검색엔진 최적화 86점이 나왔습니다.
작년에 검사했을 때 96점, 100점, 92점, 100점이었으니 성능과 SEO 점수를 다시 올리기로 했습니다!

## 성능 진단

<img alt='성능 진단' src='/images/blog/23/lighthousePerformance.png' width='450px'/>

자세한 진단을 보면 첫째로는 `Reduce initial server response time`.
서버 응답 시간이 느리다고 합니다. 이 문제는 서버의 문제도 있지만 와이파이의 성능과 관련된거기도 해서요!
첫 측정 시에는 카페에서 작업을 했던지라 집에 와서 다시 해보니 이 에러는 고쳐진 걸 확인했습니다!

### 이미지 사이즈 최적화

두번째로는 `Properly size images`. 메인 화면에 있는 사진의 크기가 적절하지 않았다고 합니다.
실제로 보여지는 거에 비해 큰 사이즈의 이미지를 가져오고 있기 때문인 것 같습니다.
`next/image`의 `sizes` 속성을 사용해 최적화를 하라고 제안하더군요!
이 메인 이미지의 경우 최대 800px으로 커질 수 있기 때문에 `sizes`를 사용해 800px으로 크기를 제한했습니다.

마지막인 `Reduce unused JavaScript`는 구글 애널리틱스 연결에 필요한 키를 넣어두지 않아서 그런거였습니다.
Vercel 설정에 환경변수를 추가함으로써 위 문제도 해결했습니다.

### SEO 진단

<img alt='SEO 진단' src='/images/blog/23/lighthouseSEO.png' width='450px'/>

첫번째로는 `Document does not have a meta description`.
문서에 meta description이 없다고 합니다.
그런데 저는 이미 meta description과 og:description을 자동으로 각 페이지에 들어가게 해뒀는데
개발자도구로 보면 og:description만 보이더라구요.
content도 null이나 빈 값이 될 리가 없게 기본값을 넣어뒀는데 말이죠!
혹시나 해서 og:description과 description의 순서를 바꿔줬더니 빠지지 않고 동작하는 걸 확인했습니다.

<img alt='요소 겹침 이슈' src='/images/blog/23/lighthouseTarget.png'/>

그리고 위 문제는 모바일 뷰로 볼 경우 저 부분 요소들이 겹쳐서 그런 거였습니다.
그래서 마진값을 수정해 해결했습니다!

기술 블로그 라이트하우스로 성능 개선하기


이 글은 [goidle 님의 리액트 톺아보기](https://goidle.github.io/react/in-depth-react-intro/), [보아즈 님의 리액트 까보기 시리즈](https://youtu.be/JadWu4Ygnyc?si=bb149nca5g9dV1Nw)
를 참고하여 공부하며 정리한 글입니다.
소중한 배움을 나눠주신 두분께 진심으로 감사드립니다.
이 장은 특히 goidle 님의 [리액트 톺아보기](https://goidle.github.io/react/in-depth-react-scheduler_1)를 주제로 합니다.
work 스케줄링을 위해 reconciler가 처리하는 사전 작업들과
scheduler가 어떻게 Work를 우선순위대로 스케줄링하고 적절한 타이밍에 실행하는지를 다룹니다.

## Work 스케줄링을 위한 사전작업

지난 장의 idle update 문단에서 리액트는 update를 적용하고자 scheduleWork 함수를 통해 Work를 스케줄링한다고 했다.
이 함수를 호출하는 reconciler는 `fiber.expirationTime` 속성을 통해 scheduler에게 Work의 스케줄을 알려준다.
`scheduleWork(fiber, expirationTime)` 함수는 아래의 일들을 한다.

1. 이벤트 발생을 알려주는 expirationTime 할당
2. 이벤트 발생 컴포넌트의 VDOM root를 가져옴
3. root에 스케줄링 정보를 기록

`react-reconciler/src/ReactFiberWorkLoop.js` 코드를 살펴보자.

![markUpdateTime 소스](/images/blog/23/markUpdateTime.png)

scheduleWork(`scheduleUpdateOnFiber`) 함수 내 `markUpdateTimeFromFiberToRoot` 함수를 보면
위 사전 작업들을 행하는 로직을 볼 수 있다.

### root

`ReactDOM.render()`로 컴포넌트를 삽입하는 부모 태그가 root이다. (`<div id='root'></>`)
한 root엔 한 VDOM이 있으며 root는 VDOM을 대표하는 변하지 않는 객체이다.
root는 한번에 Work 하나씩을 처리하는데,
그렇기에 여러 update가 발생해 여러 work를 스케줄링해야할 때, 작업의 우선순위 판단을 위해
스케줄링 정보(expirationTime)을 VDOM의 root에 기록해둔다.

### expirationTime

코드를 보면 expirationTime이 클수록 먼저 발생한 이벤트이고, 우선순위가 높다.
위 이미지 452번째 줄에서도 `fiber.expirationTime`과 인자 `expirationTime`을 비교해
만약 `expirationTime`이 더 크다면 그 값으로 할당(교체)한다.
먼저 발생한 이벤트를 먼저 처리할 수 있도록 값을 업데이트하는 것이다.
또 while 문 안에서 root 노드가 아닌 경우 `node.childExpirationTime` 속성을 사용하는데, 이 속성은
리액트 18의 concurrent 모드에서 유용히 사용된다.

또 `expirationTime`은 주어진 work가 없는 경우 `NoWork`, 동기로 처리되어야하는 work인 경우 `Sync`라는 상수로 표현된다.

## 버전16에서 대부분의 update를 처리하는 방법

![scheduleUpdateOnFiber 소스](/images/blog/23/scheduleUpdateOnFiber.png)

root까지 마킹이 끝난 후, reconciler는 expirationTime의 값으로 분기를 해 `ensureRootIsScheduled`를 실행한다.
동기적으로 호출해야하는 Work인 경우 VDOM을 처음 생성하는 시기가 아닐 때,
비동기적으로 호출해야하는 Work인 경우 바로 ensureRootIsScheduled를 실행한다.



work 스케줄링을 위해 reconciler가 처리하는 사전 작업들과 스케줄링

리액트 톺아보기 - Scheduler


![](/images/blog/23/fengicon/001.jpg)

안녕하세요. 오늘 ‘작은 공을 쏘아올리자’,
부제 ‘회사에서 성장할 수 있는 환경 만들기’라는 발표를 하게 된 프론트엔드 개발자 박하은입니다.
저는 회사에서 사내 스터디라는 작은 공을 쏘아올려 팀원들과 함께 성장할 수 있었던 경험을 공유하려고 합니다.

![](/images/blog/23/fengicon/002.jpg)

일단 제 소개를 먼저 하자면 저는 캐나다에 있는 대학에서 마케팅을 전공했습니다.
디지털 마케터가 되기 위해 통계 프로그램인 R을 한번 공부해봤는데요.
원래 저는 하나에 길게 집중을 잘 못하는데, 제가 몇시간동안 자리에서 일어나지 않고 코딩을 하고 있더라고요.
그래서 이게 내 적성인가? 싶어서 코딩 관련 강의를 몇개 들어보니까,
정말 재미있어서 마침 코로나로 한국에 들어왔겠다, 대전에 있는 대덕인재개발원에서 스프링과 JSP 위주의 개발을 배웠습니다.

![](/images/blog/23/fengicon/003.jpg)

과정을 마친 후 2020년 연말 대전의 한 SI 기업에서 풀스택 개발자로서 일을 시작했습니다.
유성구에 있는 국가정보자원관리원에 파견되어 일을 했구요.
그러다가 2022년 여름에 서울의 한 물류 스타트업으로 이직을 했습니다.
아예 프론트엔드 개발자로 진로를 정해 리액트로 주로 개발을 했습니다.
그리고 6개월 후에 있었던 인사평가에서 받았던 피드백 중에 ‘팀과 함께 성장하고 더 나은 팀 문화를 만들고자 고민하고 행동한다’는 내용이 있었습니다.
그래서 오늘 발표에서는 이 피드백을 받기까지 제가 했던 것을 나눠보려고 합니다.

![](/images/blog/23/fengicon/005.jpg)

진짜 일을 잘 하는 사람은 자기 자신을 위해 일하는 사람이라고 합니다.
회사에서 몰래 개인 프로젝트를 한다는 게 아니라, 회사를 위한 일을 하지만 나도 함께 성장하는 개발을 한다는 건데요.

![](/images/blog/23/fengicon/006.jpg)

취업을 하고 나니 아침일찍 출근해서 8시간동안 일을 하고 집에 오면 에너지가 남아있지 않더라구요.
그래서 개인적인 공부나 사이드 프로젝트를 하는게 쉽지 않았습니다.
또 새 회사의 팀에는 중니어와 시니어보다 주니어가 더 많았습니다.
기술적으로 고연차 팀원에게 의존할 수만은 없는 상황이었기 때문에,
회사에서 스스로 성장할 수 있도록 환경을 조성해야겠다는 생각이 들었습니다.

![](/images/blog/23/fengicon/007.jpg)

그래서 맨 처음엔 팀원 한명과 일대일 스터디를 시작했습니다.
그러다 3명이 자발적으로 조인해 5명이 되었습니다.
일주일 회고, 함수형 프로그래밍, next.js 등등 다양한 주제를 함께 공부했는데요.
사내 스터디다보니 업무에서 쓰기로 한 기술을 함께 공부해서 직접 써볼 수 있었습니다.
한 가지 예시로, next.js 스터디를 한 후 사내 리액트 CRA 프로젝트를 next.js로 전환하기도 했습니다.

![](/images/blog/23/fengicon/008.jpg)

이렇게 팀원들과 같이 스터디를 하고, 함께 성장해서 좋았던 점은 크게 3가지가 있었습니다.
첫째로, 업무를 하다보면 바빠서 내 업무만 보게 될 때가 있는데요.
스터디를 하니까 서로의 아웃풋을 주기적으로 공유할 수 있었어요.
업무 외적으로 하고 있는 개발이나 방향성에 대한 대화를 많이 할 수 있었고,
동료와 같은 곳을 바라보고 있다는 라포가 형성되어 팀워크가 좀 더 강해지는 걸 느꼈습니다.
또 저는 팀원들의 실력이 좋아진다는 건 내 환경이 좋아지는 거라고 생각하는데요.
이런 이유로 실제로 네카라쿠배당토 같은 기업들이 사내 스터디를 장려하고 있기도 하죠.
함께 스터디를 하면서 서로 모르는 걸 알려주고, 보완해줄 수 있습니다.
마지막으로, 개발자 동료가 생깁니다. 회사 동료를 떠나서 함께 개발 이야기를 하고,
기술적인 토론을 할 수 있는 개발자 친구들이 생깁니다.
같은 도메인에서 같은 기술을 사용해본, 누구보다 더 서로를 공감할 수 있는 동지가 생깁니다.

![](/images/blog/23/fengicon/009.jpg)

그럼 사내 스터디를 시작하기 전 우리가 가져야할 마인드셋은 뭐가 있을까요?
첫째로, 공유하는 것을 아까워하지 말아야합니다.
나만 알아서 남보다 더 좋은 성과를 내고 싶을 수도 있고,
힘들게 찾은 황금 정보라 나만 알고 싶을수도 있습니다.
그러나 일단 내가 아는 정보는 남도 알고 있을 확률이 높습니다.
남이 알던 나만 알던 일단 ‘나는 이해했으니까 됐다’라고 생각해야합니다.
내가 제대로 이해했다면 그걸로 된 것입니다.
또 누군가와 아티클을 같이 읽고 이야기해보면 혼자 읽었을 때보다
더 잘 이해하게 되거나 시너지가 날 수도 있습니다.
마지막으로, 양질의 기술 정보를 팀원들에게 계속 공유해준다면
인사 평가에도 긍정적인 영향이 갈 수 있습니다.

![](/images/blog/23/fengicon/010.jpg)

즉, giver가 되자는 뜻입니다.

![](/images/blog/23/fengicon/011.jpg)

남에게 주는 것은 내 지식을 뺏기는 것이 아닙니다.
남에게 지식을 전해주기 위해서는 그 전에 내가 그것을 완벽히 이해해야 합니다.
결과적으론 남에게 주는 것보다 나에게 남는 경험과 지식이 더 큽니다.

![](/images/blog/23/fengicon/012.jpg)

두번째로, 스터디를 시작할 때 우리는 리더가 되어야합니다.
많은 개발자분들께서 ‘아 진짜 공부해야되는데…’라고 말합니다. 하지만 시작이 어렵죠.
그렇기에 우리는 리더가 되어서 스터디를 주도해야합니다.
스터디 일정을 계획하고, 일정이 밀린다면 어느 날 딱! 하자고 결단을 내린다던가 사람들을 독려할 수 있어야합니다.
그런데 만약 스터디를 제안하는 거 자체가 어렵다던가 어떻게 말을 꺼내야할지 모르겠다면 어떻게 하는게 좋을까요?

![](/images/blog/23/fengicon/013.jpg)

제가 사용했던 방법은 "함께 발전하고 싶다고 자연스럽게 느끼게 하기”였는데요.

![](/images/blog/23/fengicon/014.jpg)

아래의 이미지는 사내 디자인시스템 컴포넌트를 설계했을 때 정리했던 내용의 일부입니다.
이 디자인시스템을 공유할때 그냥 ‘이렇게이렇게 해서 써라'라고 하지 않고,
설계를 할때 어떤 고민을 했고 어떤 방법으로 그 문제를 해결했는지 등등 최대한 내용을 자세히 담아 팀 회의때 공유했었습니다.
다들 업무를 하면서 새로 알게 된 내용이나 업무 관련 기술을 잘 정리하고 계실 것 같은데요.
그 문서를 혼자 보시기보다는 살짝 다듬어서 팀원들에게 공유해보는건 어떨까요?
저는 이렇게 정리했던 걸 공유하기 위해서 글을 다듬고,
또 혹시나 질문이 들어오면 답을 해줘야하니까 좀 더 자세하게 찾아보는 과정에서 많이 배웠던 것 같습니다.
그리고 이렇게 몇번 하니까 팀원분들이 저를 ‘성장 욕구가 큰 사람, 새로운 걸 배우는 걸 즐거워하는 사람'으로 봐주시더라고요.

![](/images/blog/23/fengicon/015.jpg)

그렇게 빌드업을 이제 해뒀으면, 성장 의지가 강해보이는 한 사람 또는 소규모 인원에게 스터디 제안을 해보세요.
저도 향상심을 가지고 있는 동료 한명에게 스터디를 슬쩍 제안하는 걸로 시작했었는데요.
스터디를 하게 되면 모든 구성원이 시간과 노력을 기여해야합니다.
그렇기에 스터디 구성원을 무작정 늘리기보단 향상심을 가진 소규모 인원 위주로 시작하는 것을 추천드립니다.

![](/images/blog/23/fengicon/016.jpg)

그럼 이제 어떻게 스터디를 진행했는지 이야기해드릴게요.
저는 무조건 아웃풋이 있는 스터디를 하는 편입니다.

![](/images/blog/23/fengicon/017.jpg)

제가 가장 추천하는 방법은 정해진 내용을 각자 공부해와서 각자 인출하는 건데요.
칠판이나 종이에 주제만 적어두고 공부한 내용을 요약해서 모두 적어봅니다.
그 다음 각자 적은 내용을 설명해봅니다. 빠뜨린 내용이 있다면 되짚어보면서 보완합니다.
이렇게 하면 내가 모르는 게 뭔지 확실히 알 수 있고, 설명하는 연습을 하면서 면접 대비도 됩니다!
만약 모른다는 사실을 밝히기 부끄러운 분이 있다면 각자 노트에 적는 것도 좋습니다.

![](/images/blog/23/fengicon/018.jpg)

실제로 제가 스터디를 했던 모습입니다.
회사 회의실에 화이트보드가 있어서 거기서 했구요.
이런식으로 아웃풋이 있는 스터디를 했습니다.
공부한 걸 직접 설명해볼때 훨-씬 기억에 오래 남는다는 걸 느낄 수 있었습니다.

![](/images/blog/23/fengicon/019.jpg)

그 외에 추천하는 방법은 아예 그자리에서 같이 읽고 이야기해보는 것입니다.
이 방법은 짧은 아티클이나 배경 지식이 어느정도 있는 내용에 추천합니다.
또는 다양한 리소스를 활용해도 좋습니다.
꼭 어떤 책이나 강의의 커리큘럼을 따라가는게 아니라, 돌아가면서 읽고 싶은 아티클을 가져와
다같이 읽어보세요. 아마 다들 ‘나중에 읽어야지’하고 즐겨찾기해둔 글이 많으실 것 같은데요.
북마크했던 글들을 읽기에도 좋고, 다양한 주제다보니 덜 지루하게 느껴집니다.
마지막으로 회고 스터디를 추천드립니다.
새로 배운 것이나 했던 업무를 회고해보는 겁니다.
지난 한주간 마주쳤던 기술적인 이슈를 어떻게 해결했는지나 개인적으로 공부했던 내용을 가볍게 이야기해볼 수 있어 좋습니다.

![](/images/blog/23/fengicon/020.jpg)

그런데 만약, 아예 스터디를 같이 할 만한 팀원 자체가 없거나,
기술적인 내용을 계속 공유했는데도 아무 피드백이 없다면 어떻게 해야할까요?

![](/images/blog/23/fengicon/021.jpg)

이런 척박한 환경 속에서 우리는 그냥 ‘나 혼자 공을 쏘아올린 사람’이 됩니다.
무력감이나 실망감을 느낄 수 있습니다.
하지만 생각해보면 공을 쏘아올리는 과정 자체가 나에게 배움의 기간입니다.
그 과정을 통해 새로운 기술이나 몰랐던 것을 배우고, 문서화하는 경험을 했을테니까요.
이렇게 한번 작은 공을 쏘아올렸으니, 다른 작은 공을 쏘아올리는게 더 쉬워집니다.
또 그 작은공을 회사 밖에서 쏘아올릴 수도 있겠죠!

![](/images/blog/23/fengicon/022.jpg)

결론적으로 제가 이 발표를 통해 하고자 하는 말은 ‘내 환경을 내가 선택하자’는 것입니다.
무작정 ‘회사가 별로면 퇴사해버려!’라는게 아니라, 작은 공을 쏘아올려서 그 환경을 나의 성장을 위한 발판으로 삼자는 것입니다.
지금 환경이 척박하더라도 그 작은 공을 쏘아올리는 순간 우리는 성장하니까요.

어떤 행동경제학 연구에 따르면 ‘진정한 동기 부여는 팀워크와 성취감, 어려움 극복에서 나온다’고 합니다.
마라톤을 하는 사람들의 표정을 보면 너무 힘들어보이지만 그럼에도 그들이 달리는 이유는 그들의 동기가 내면에서 나오기 때문이라고 합니다.
42킬로미터를 달렸다는 성취감, 함께 달리는 사람들과의 연대, 그리고 체력적 한계를 극복하는 것.
프로젝트를 해내는 개발자들과 비슷할 것 같은데요.
여러분도 혼자 또는 팀의 동료들과 함께 작은 공을 쏘아올려보면 어떨까요?
더 즐겁게, 자발적으로 일할 수 있게 될 겁니다.

![](/images/blog/23/fengicon/023.jpg)

감사합니다.


사내 스터디 리딩 경험을 나눴던 발표 내용을 공유합니다.

작은 공을 쏘아올리자 : 회사에서 성장할 수 있는 환경 만들기


[goidle 님의 리액트 톺아보기](https://goidle.github.io/react/in-depth-react-intro/), [보아즈 님의 리액트 까보기 시리즈](https://youtu.be/JadWu4Ygnyc?si=bb149nca5g9dV1Nw)를 참고하여 공부하며 정리한 글입니다.
이 글은 그중에서도 goidle 님의 [React 톺아보기 - 03. Hooks_1](https://goidle.github.io/react/in-depth-react-hooks_1)를 주제로
공부한 내용입니다.
리액트를 더 잘 이해할 수 있도록 자세히 설명해주신 두분께 리액트 개발자로서 진심으로! 감사드립니다.
이 글은 위 두 리소스에 맞춰 리액트 버전 16을 기준으로 하고 있으며, 18 코드와 비교해 볼 수 있는 부분도 중간중간 언급됩니다.

## VDOM

Virtual DOM은 일종의 programming concept다.
메모리 안에 저장되어있으며 ReactDOM 등의 라이브러리에 의해 실제 DOM과 동기화된다.

<img alt='Virtual dom' src='/images/blog/23/vdom.png' width='400px'/>

VDOM은 fiber 노드들로 구성된 **트리** 형태로 구현되어있고, **더블 버퍼링** 구조로
DOM에 마운트된 fiber를 의미하는 **current** 트리와 render phase에서 작업중인 fiber인 **workInProgress**를 가진다.
workInProgress에 있는 fiber는 commit phase를 지나서 current 트리에 속하게 된다.
각 노드는 하나의 child를 가지고, 부모는 return으로 참조한다.

위 이미지에서 보듯 workInProgress 트리의 노드는 current 트리에서 자기복제를 해서 만들어지고, 이 노드들은 서로를 alternate으로 참조한다.

### fiber

**fiber**란 VDOM의 노드 객체인데, react element의 내용이 DOM에 반영되기 위해서는 먼저 VDOM에 추가되어야한다.
이를 위해 확장한 객체가 바로 fiber다. fiber는 컴포넌트의 상태, 라이프사이클, 훅 등을 관리한다.

## 리액트 라이프사이클

### render phase

VDOM을 재조정(reconciliation)하는 단계로, element(Fiber)가 추가/수정/삭제되면 reconciler가 work를 스케줄러에 등록한다.
이때 말하는 work란 reconciler가 컴포넌트의 수정사항을 DOM에 적용하기 위해 수행하는 일을 말한다.
스케줄러는 등록된 work를 타이밍에 맞춰 수행한다.

이때 reconciler의 설계가 리액트 V16부터는 stack에서 fiber architecture로 바뀌었다.
Stack 아키텍처를 사용할 경우 스택의 LIFO 특성상 렌더링 순서를 조정할 수 없는데, Fiber 아키텍처를 도입하면서, 순서 조정이 가능해져
순서가 유연한 렌더링을 할 수 있게 되었다.

### commit phase

재조정한 VDOM을 동기적으로 DOM에 적용(동기화)하고 라이프사이클을 실행하는 단계다.
DOM에 적용을 일괄 처리한 후 리액트가 콜 스택을 비우고 브라우저가 paint한다.
브라우저가 paint를 하기 위해선 리액트 DOM 조작이 완전히 끝난 상태여야한다.

## 컴포넌트를 호출하면 일어나는 일

JSX로 만들어진 컴포넌트를 호출하면 babel이 `React.createElement()`를 해 리액트 엘리먼트를 반환한다.
이 React element는 type, key, props, ref 등을 가진다. 이후 변화가 있는 부분을 VDOM에 새로 적용(reconcile)하는 과정까지를 렌더링이라고 한다.
이후 renderer가 컴포넌트 정보를 DOM에 삽입하는데, 이것을 mount된다고 한다.
이후 브라우저가 DOM을 페인트한다.

## Hook을 호출하면 일어나는 일

Hook을 호출하면 Scheduler와도 상호작용을 한 후 reconciler와 상호작용을 한다.

리액트는 Task를 비동기적으로 실행한다. 스케줄러(Scheduler)가 그 Task들의 실행 타이밍을 아는 패키지이다.

Reconciler는 Fiber architecture에서 VDOM 재조정을 담당한다.

### React hook은 어디서 오는가

코드에서 hook 호출 -> `react/React` -> `react/ReactHooks` ->
`react/ReactCurrentDispatcher` -> `react/ReactSharedInternals` ->
`shared/ReactSharedInternals` -> reconciler

우리가 `useState`, `useEffect`를 사용할때 react 패키지에서 가져온다. 그 코어 패키지 안으로 들어가면
`ReactHooks.js`에서 hook들을 import하고 있다. 이 파일 안에선 `ReactCurrentDispatcher.current`를 반환하는 `resolveDispatcher()`를 갖고 있다.
그래서 또 `ReactCurrentDispatcher.current`를 따라가보면 훅 관련해 구현되어있는 내용이 없다.

즉, react 코어 패키지는 React element 관련 정보만 알고, hook에 대한 정보를 갖고 있지 않는다.
훅은 react element라는 클래스가 인스턴스화된 후, 그 객체의 상태를 관리하는 것이기에 hook과 관련된 세부 내용은 react 패키지에선 알지 못하는 것이 맞다.
훅은 `ReactCurrentDispatcher.current`을 통해 외부로부터 주입(DI) 받으며, 리액트 엘리먼트가 reconciler에 의해 fiber로 확장되어야 hook을 포함한다는 걸 알 수 있다.

훅은 shared 패키지에서 import 해오는데, shared 패키지는 모든 패키지가 공유하는 공유 패키지이다.
[reconciler의 ReactFiberHooks.js에서 renderWithHooks 함수](https://github.com/facebook/react/blob/b53ea6ca05d2ccb9950b40b33f74dfee0421d872/packages/react-reconciler/src/ReactFiberHooks.js#L375)를 통해 hook을 주입한다.
훅은 `react-reconciler` 패키지의 `ReactFiberHooks.js`이 주입하는데, 이 파일의 `renderWithHooks` 함수가 훅을 주입하며 컴포넌트를 호출하는 역할을 한다.

위 함수가 하는 일들은 아주 많지만 이런 것들이 있다. 아래의 VDOM 구조 이미지와 함께 보면 좋다.

<img alt='Virtual dom' src='/images/blog/23/vdom.png' width='400px'/>

1. `currentlyRenderingFiber = workInProgress;`: 현재 작업중인 fiber를 전역으로 잡아둠
2. `current`가 존재하면 `current.memoizedState`을 `nextCurrentHook`에 할당하고, 없으면 `null`을 할당한다.
위 VDOM 그림에서 Current 노드는 current 트리 안에 존재한다.
즉 이미 마운트되어 dom에 정보가 반영된 파이버(`current`)가 있으면 `nextCurrentHook`에 `current.memoizedState`을 할당한다.
기존에 들어있던 `current.memoizedState`가 hook일 거라고도 예상할 수 있다.
3. `nextCurrentHook`이 있으면 `ReactCurrentDispatcher.current`에 `HooksDispatcherOnMount`를 할당하고, 없으면 `HooksDispatcherOnUpdate`를 할당한다.
4. `nextCurrentHook`, `firstWorkInProgressHook`과 같은 전역변수를 현재 작업중인 컴포넌트에서만 사용할 수 있도록
작업이 끝날 경우 초기화시킨다
5. `let children = Component(props, refOrContext);`: 컴포넌트 호출.
이때 이 컴포넌트가 마운트되어야하면 전역변수 `firstWorkInProgressHook`에 훅 리스트가 생성되어 저장된다.
그 후 이 변수를 fiber의 `memoizedState`에 저장해 훅을 컴포넌트와 매핑시킨다.

5번을 통해 2번을 이해할 수 있다. `current.memoizedState`가 존재하면 그 컴포넌트는 첫 생성(mount)가 아니라
update되는 것이고, 훅 리스트 또한 이미 존재한다는 거다. 그렇게 3번에서도 mount/update 여부를 구분해
그에 맞는 훅 구현체(`HooksDispatcherOnMount`, `HooksDispatcherOnUpdate`, etc)를 사용한다.

## Hook 생성과 관련된 구현체들

<img alt='hook과 관련된 구현체들' src='/images/blog/23/hookStructure.png'/>

위 3번에서 등장한 `HooksDispatcherOnMount`는 useState 속성으로 `mountState` 함수를 가진다.
즉, useState를 호출한다는 것은 mountState를 호출하는 것이다.
useState를 호출하면 Hook 객체를 생성한다. 그 Hook 객체는 하나의 큐 객체를 가지고, 그 큐 객체는 하나의 update 객체를 가진다.

### mountState

<img alt='reactFiberHooks' src='/images/blog/23/mountStateV16.png'/>

mount 구현체인 `mountState`를 타고 들어가서, hook 객체를 생성하는 함수인 `mountWorkInProgressHook`으로 들어가본다.
(리액트 버전 18에서부턴 `mountStateImpl`이 hook을 반환하고, `mountWorkInProgressHook`으로 타고 들어갈 수 있다.)
`mountWorkInProgressHook`에서 생성하는 hook은 `memoizedState`, `queue`(큐 객체), `next`(다음 hook을 가리키는 포인터) 등의 속성을
가진다. (버전 16과 18의 속성이 살짝 다르다)
그 다음엔 작업중인 훅(`workInProgressHook`)이 없으면 위에서 생성한 hook을 `workInProgressHook`에 할당한다.
만약 현재 작업중인 훅이 있으면 그 훅을 `workInProgressHook`의 `next`로 넣어놓는다.
다시 `mountState`로 돌아와서 보면 `queue` 객체(`hook.queue`)를 생성하고,
`dispatchAction`에 `currentlyRenderingFiber`와 `queue`를 [바인딩](https://ko.javascript.info/bind)해 `dispatch` 함수를 만든다.
그리고 `[hook.memoizedState, dispatch]` 배열을 반환한다. 이 리턴값은 `useState`의 반환값이 된다.

## 훅은 어떻게 상태를 변경하고 컴포넌트를 리렌더링 시키는가

바로 위 문단에서 알아본 대로 `setState`는 사실상 `dispatch`, 즉 `dispatchAction` 함수이다.
이 함수는 상태를 변경하고 컴포넌트를 리렌더링하기 위해 크게 4가지 역할을 한다.
update 객체 생성 -> update를 큐에 저장 -> 불필요한 렌더링이 없도록 최적화 -> update를 적용하고자 Work를 scheduler에 예약한다.

위에서 VDOM을 설명할 때 current 트리와 workInProcess(이하 WIP) 트리가 있다고 했다.
`dispatchAction` 함수에서는 fiber가 `currentlyRenderingFiber`(현재 WIP에 있는 fiber)인지 확인하고 그 alternate까지 더블체크한다.
WIP의 fiber가 current에 반영될 때 기존 current와의 연결을 끊고 자기자신을 복제하여 새로운 workInProgress 노드를 만들기 때문이다.
체크해서 만약 현재 렌더링하고 있는 fiber가 없을 경우는 idle 상태로, render phase에 진입하지 않은 상태이다.
주어진 update가 없는 상태의 idle update의 과정을 먼저 알아본다.

### idle update

1. update 객체 생성: update 객체는 `expirationTime`, `action`(`setState` 인자로 넣을 값), `next`(다음 객체를 가리키는 포인터) 등을 가진다.
2. update를 queue에 저장: 그다음 update 객체를 list의 마지막에 넣는다.
그리고 2번째 업데이트부터는 첫번째 update 객체를 마지막 update의 next로 지정해 원형 링크드 리스트로 만든다.
3. 불필요 렌더링이 없도록 최적화: fiber와 alternate의 `expirationTime===NoWork`이면(스케줄러에 등록된 work가 없으면) `return;`을 통해 `dispatchAction`을 실행 중단한다.
4. update를 적용하고자 Work를 스케줄링: 3에서 실행 중지하지 않았을 경우 `scheduleWork` 함수를 통해 Work를 스케줄링한다.

4번에서 Work를 스케줄링하면 idle 상태를 벗어나 render phase에 진입한다.

### render phase update

render phase update란 이미 다른 스케줄링된 업데이트가 있는 상황에 추가로 업데이트가 발생한 것이다.
리액트 톺아보기의 예시를 들수 있다.

```js
    function FC() {
        const [a, setA] = useState(0)
        if (a === 1)
            setA(2)
        return <button onClick={() => setA(1)}></button>
    }
```

위 코드에서 `button`을 클릭하면 `setA(1)`이 실행된다.
`setState` 함수가 실행되었으므로 컴포넌트가 다시 렌더링되는데, `if(a===1)`문에 걸려 `setA(2)`에 닿는다.

render phase update 상태에서는 크게 3가지의 일을  처리한다.

1. 해야할 update를 임시 저장
2. update가 추가적으로 발생하지 않을때까지 컴포넌트를 호출해 update를 소비
3. 소비 중에 render phase update가 끊임없이 발생하면 에러 띄우기

render phase update의 경우 idle update와 달리,
Work가 이미 스케줄링 되었으므로 scheduleWork를 하거나 성능 최적화를 할 필요가 없다.
버전 16 리액트 코드와 함께 이 3가지를 살펴보자.

### update 임시 저장

<img alt='render phase update' src='/images/blog/23/renderPhaseUpdateV16.png'/>

render phase에 진입했으므로 전역변수 `didScheduleRenderPhaseUpdate`를 `true`로 설정한다.
update 객체를 만들고, update들을 담을 전역변수 Map(`renderPhaseUpdates`)을 만든다.
이 임시 저장소가 있어야 다음 컴포넌트 호출 때 update를 꺼내 소비할 수 있다.
update를 queue 객체를 키로 삼아 이 `renderPhaseUpdates`에 임시 저장해둔다.

### renderPhaseUpdates 소비

<img alt='renderWithHooks' src='/images/blog/23/renderWithHooksV16.png'/>

위 단계에서 저장한 update는 renderWithHooks 함수가 소비한다.

렌더링 횟수를 카운트하며 `nextCurrentHook`, `currentHook`, `workInProgressHook` 등
update를 소비하는데 필요한 값들을 초기화한다. 그러다 466번째 줄에서 Component를 한번 더 실행했을 때
컴포넌트를 리턴하기 전에 setState가 또 호출될 경우(update가 또 있을 경우) dispatchAction 안의
구문이 재실행되며 위 과정이 반복된다.

### 반복되는 리렌더링 방지

<img alt='too many rerenders' src='/images/blog/23/tooManyRerenders.png'/>

반복하는 횟수(`numberOfReRenders`)가 제한(`RE_RENDER_LIMIT`)을 초과하면 `Too many rerenders.` 메시지를 띄운다.

## 결론

위에서 알아본 것과 같이 리액트는 훅을 통해 컴포넌트 상태를 업데이트하고,
업데이트를 반영할 Work를 Scheduler에 전달하고, Scheduler는 스케줄링된 task를 적절한 시기에 실행한다.
다음 장에서는 reconciler가 Work를 스케줄링하기 위해 하는 사전작업과 스케줄러가 행하는 일들을 더 자세히 알아본다.


VDOM, Fiber, 리액트 라이프사이클, 훅을 통해 컴포넌트 상태를 업데이트하는 과정

리액트 톺아보기 - Hooks


![input 비교](/images/blog/23/myBack.jpg)

## 상반기 목표와 결과

연초에 적었던 상반기 목표는
1. 유연하고 단단한 컴포넌트 설계법 배우기
2. 함수형 프로그래밍 공부
3. 자바스크립트 철학을 이해하고 JS, 리액트, 타입스크립트 더더더 공부하기
였다.

이 목표들의 달성 여부를 하나하나 따져보겠다.

## 유연하고 단단한 컴포넌트 설계법 배우기

리액트로 개발을 하면 컴포넌트를 합성하는 일이 잦다.
컴포넌트 합성과 재사용을 하면서 동시에 컴포넌트 별로 커스텀해야하는 부분들이 있기에
변화에 유연하면서도 단단한 컴포넌트를 만드는 법을 연습하는 게 중요하다고 생각해서 세웠던 목표다.

![input 비교](/images/blog/23/inputDesign1.png)

감사하게도 회사에서 공통 컴포넌트 설계 업무를 맡아 해볼 수 있었다. MUI `TextField`를 기반으로
`textarea`, 기본 텍스트 인풋, 검색어 인풋, `counter` 컴포넌트를 만들어야했다.
처음엔 위 이미지처럼 각 컴포넌트를 모아두고 공통점과 차이점을 비교해보면서 어떤 부분은 공통화하고 커스텀해야할지 생각해보았다.
counter를 제외한 세 컴포넌트의 공통점은 사용자가 text를 입력할 수 있고 validation 값에 따라 아래에 문구가 붙을 수 있으며
input 내부에 고정된 요소가 있을 수 있다는 거였다. 그러면서도 그 요소들은 각 페이지에 따라 조립하는 것처럼 넣었다 뺄 수 있어야했다.
그래서 **Compound Components** 디자인 패턴을 사용해 `input` 내/외 요소의 위치와 디자인은 디자인 시스템(공통 컴포넌트) 단에서 고정해두고
더 자세한 내용물은 각 컴포넌트에서 구현하도록 하였다.

이 작업은 나의 사수인 희동님이 이끌어 주셨는데, 정말 배운게 많았다.
희동님은 공통 컴포넌트를 설계할 때 **스타일, 레이아웃, 동작(메서드), 용어**를 먼저 생각해보라고 하셨고
코드 가독성을 위해 JSX 태그만 보고도 이 컴포넌트의 레이아웃을 알 수 있게 설계하자고 하셨다.
그래서 Compound Components 패턴을 사용했는데,
그렇게 하고 나니까 조합해 사용하는 것도 쉬웠고 리액트의 선언적 특성을 살릴 수 있었던 것 같다.
참 뿌듯했던 공통 디자인 컴포넌트 설계, 구현 경험이었다.

그럼에도 100% 달성!한 목표는 아닌 것 같고 앞으로도 유연하고 단단한 컴포넌트를 설계할 수 있도록
디자인 패턴 공부도 좀 더 하고 잘 만들어진 오픈 소스 라이브러리들의 코드도 좀 까볼 예정이다.

## 함수형 프로그래밍

함수형 프로그래밍 배우기!를 결심한 이유는 첫번째 목표와 조금 연결된다.
어떻게 해야 코드를 잘 짤 수 있을까 생각하다가 함수형 프로그래밍을 배워보면 좋을 것 같아
인프런 함수형 강의를 수강하기 시작했다. 강의 1편을 다 들어서 하반기에는 응용편을 들어야한다.
*쏙쏙 들어오는 함수형 코딩*이라는 책으로 스터디도 하고 있다.

일단 지금까지 함수형 프로그래밍을 해본 바로 가장 좋았던 건 코드를 지연적으로 실행할 수 있다는 거였다.
어떤 값이 필요할 떄 그걸 다 만들어놓고 시작하는게 아니라, 이터레이터를 만들어두고 지연적으로 실행시킬 수 있으니까
성능 개선에 꽤 도움이 될 것 같다. 또 단일 책임 원칙도 지키면서 가독성과 낮아진 유지보수 난이도까지 한번에 챙기는...
또 자바스크립트도 점점 함수형을 도입하고 있는 만큼, 내가 사용하는 언어가 나와 같은 곳을 바라보고 있는 것 같아 더 좋았다.
다만 실무에서는 별로 안 써봐서, 개인 프로젝트를 먼저 함수형으로 리팩토링하려고 한다.

## JS TS와 리액트

자스, 타스, 리액트 모두 작년보다 더 친해지긴 했지만 얘네가 워낙 빨리 발전하고 있는 만큼 딱 맞춰 따라가기가 어렵다.
코어 자바스크립트도 한 번 더 읽고 모던자바스크립트 딥다이브도 스터디하고 있지만 아직 아쉽다.

## 젤리주도개발자들

![달력](/images/blog/23/cal.png)

올 상반기에는 스터디를 정말 많이 했다. 출근 전, 퇴근 후 팀원들이나 아는 개발자 친구들과 스터디를 해서 세보니까
상반기에만 한 60회 정도를 했다. [혼공컴운](https://github.com/pullingoff/CAOS),
코어자바스크립트, [모던자바스크립트 딥다이브](https://github.com/Jellies-Study/Modern-JS),
[쏙쏙 들어오는 함수형 코딩](https://github.com/Jellies-Study/Grokking-Simplicity) 책 스터디부터
next.js, [함수형 프로그래밍 강의 스터디](https://github.com/pullingoff/ES6plus-Study)와 각자 배운 내용을 나눠보는 회고 시간 등등
업무 시간 외에도 개발 공부를 계속 하려고 노력했다.
개인적으로 [프로그래머스 알고리즘 문제](https://github.com/pullingoff/algorithm)도 PREP에 맞춰 꾸준히 풀었다!

스터디도 하고 회사일도 하고 심지어 방통대 컴퓨터과학과에까지 편입을 해서...
일정이 정말 바빠 가슴이 답답하거나 피곤할 때도 있었지만
일할 때 가장 중요한 게 동료, 최고의 복지도 좋은 동료라고 생각하는 나로써는
같이 달리는 팀원들이 있었기에 이 일정을 소화할 수 있었던 것 같다.

![카톡 캡쳐](/images/blog/23/ball.png)

이건 좀 자랑인데, 팀원한테 이런 말도 들었다.
왜냐면 제가 블로그 만들기 스프린트인 `Next.js로 블로그만들기 스파르타`를 개최해서
그 중 한분이 개인 블로그를 완성하셨그든요!!!

굳이 바깥에서 사람을 찾는게 아니라, 내 회사 동료들과 같이 공부하고 성장하니까
우리 사이의 유대도 커지고 팀워크도 좋아지고 업무할 때도 더 손발이 잘 맞게 되어 좋았다.
또 스터디를 만들고 인원을 늘리며 관리해온 과정은 **회사에서 작은 공 쏘아올리기**라는 제목으로
올 9월에 있을 펜지니어 컨퍼런스에서 좀 더 나눠볼 예정이다.

## 하반기 목표

그래서 2023년의 하반기 목표는

1. 혼공컴운/네트워크/모던자스/쏙코딩/이코테 1회독
2. 함수형강의 응용까지 완강
3. 개인프로젝트 함수형 프로그래밍 도입해 리팩토링 & 수치적인 성능 변화 기록할 것
4. 알고리즘 문제 주 3개 이상
5. 뜯어볼 코드 정하고 뜯어보기

이다.
그럼 이만 🎀오늘의 회고 끝🎀

2023년 상반기 회고


## 요약

짧게 요약한 내용입니다.

<img width="700" alt='회원가입 as-is' src='/images/blog/2305/ex-asis.png' />

이랬던 코드를 

<img width="700" alt='회원가입 to-be' src='/images/blog/2305/ex-tobe.png' />

이렇게 바꾸었습니다.

## 도입 계기

```typescript
    const [status, setStatus] = useState<{
        idMsg: string,
        idOk: boolean,
        isIdChecked: boolean,
        passwordMsg: string,
        passwordOk: boolean,
        confirmPasswordMsg: string,
        confirmPasswordOk: boolean,
      }>({
        idMsg: '',
        idOk: false,
        isIdChecked: false,
        passwordMsg: '',
        passwordOk: false,
        confirmPasswordMsg: '',
        confirmPasswordOk: false,
    });
```

원래는 비밀번호, 비밀번호 재입력 필드가 validate한지 여부를 담는 불린값(`passwordOk`)과 
그 상태에 따른 에러 또는 성공 메시지(`passwordMsg`)을 상태로 가지고 있었습니다.
원래 상태를 관리할 때 상태(`password`) 외에 그 상태에 따라 결정되는 값(`passwordMsg`, `passwordOk`)은 상태에 담지 않는게 맞는데요.

```js
    if (!values.password || !PW_REGEX.test(values.password)) {
      _errors.passwordOk = false;
      _errors.passwordMsg = MSG.RULE_PW;
    }

    if (!values.confirmPassword || values.password !== values.confirmPassword) {
      _errors.confirmPasswordOk = false;
      _errors.confirmPasswordMsg = MSG.WRONG_PW;
    }
    setStatus(_errors);
```

기존 코드를 저렇게 작성했던 이유는 필드 간의 의존성 때문이었습니다.
비밀번호가 바뀔 때마다 정규 표현식에 맞는지 확인하고 바로바로 에러메시지를 표시해줘야 했고, 비밀번호 확인 필드가 그 비밀번호와 일치하는지 다시 밸리데이션해야했습니다. 
이런 값들을 JSX 내부에서 그때그때 밸리데이션하게 하기보단 state로 분리해서 `onChange` 내에서 검사 후 `setStatus`를 한번에 하도록 했었어요.  

이 방법이 베스트가 아니라는 걸 알면서도 구현했던 거지만
밸리데이션 내용이 너무 길어졌고, 코드가 복잡해져 어떤 코드를 수정할 때 다른 부분에도 영향이 갈까봐 찝찝해지기 시작했습니다.

그래서 <a href='https://react-hook-form.com' target='blank'> **react-hook-form**</a>을 적용해보았고, 아주 만족 중입니다!

## react-hook-form이란?

react-hook-form, 줄여서 rhf는 폼을 관리하고 활용할 수 있는 커스텀 훅들을 제공해줍니다. 사용가능한 훅들은 이런 것들이 있습니다.

- `useForm`: 폼을 간단하게 관리할 수 있는 커스텀 훅.
- `useController`: MUI처럼 외부에서 제어하는 컴포넌트들의 input을 제어하고 싶을 때 사용합니다. 컴포넌트별로 `useController`를 만들고, `useForm`과 따로 씁니다.
- `useFormContext`: `formContext`에 접근할 수 있고 `useForm`의 메서드를 사용할 수 있습니다. 폼 컨텍스트를 prop으로 넘기기 불편한, 깊게 nested 된 구조에 쓰면 좋습니다.
- `useFormState`: 각 폼 상태를 구독하고, 커스텀 훅 레벨에서 리렌더링을 분리하고 싶을때 사용합니다.
- `useFieldArray`: 필드들을 배열로 관리해 다이나믹하게 필드를 추가하거나 삭제, 순서를 바꾸고 싶을 때 사용합니다.

그 중에서도 저는 가장 기본적인 <a href='https://react-hook-form.com/docs/useform'>`useForm`</a>을 사용하였습니다. 예시코드를 보겠습니다.

## useForm 연동

```jsx
    import { SubmitHandler, useForm } from 'react-hook-form';
    
    const 회원가입 = () => {
        const {
            register,
            handleSubmit,
            formState: { errors },
        } = useForm<FormValues>({
            mode: 'onChange',       // validation을 언제 할지
            defaultValues: {        // input들의 기본값 설정
                userId: '',
                password: '',
                confirmPassword: '',
            },
        });
        return (
            // 생략
        )
    }
```

가장 먼저, `useForm`을 세팅했습니다. `mode` 속성으로 `onChange`마다 validation 하도록 변경해주었습니다.
기본 설정은 `onSubmit`으로, 폼이 submit될 때에만 밸리데이션 처리를 합니다. 
위 폼에선 회원가입에 필요한 `userId`, `password`, `confirmPassword` 필드를 관리합니다.
`useState`와 비슷한 구조로 `defaultValues`를 지정해줍니다.

```jsx
    // 비밀번호 인풋
     <PasswordInput
         // name='password'
         // value={values.password}
         // onChange={handleChange}
        {...register('password', {
            deps: ['confirmPassword'],   // 의존성 연결
            pattern: {                   // 정규표현식 패턴
                value: PW_REGEX,
                message: '비밀번호는 숫자와 영어, 특수문자를 포함해주세요.',
            },
        })}
    />
```

그 다음은 `register` 메서드를 사용해 인풋과 연동합니다. 이 코드의 비즈니스 로직 중 하나가
'*비밀번호 입력값이 변경될때마다 비밀번호 확인 필드도 다시 확인해 바로바로 에러메시지를 띄운다.*'입니다.

그렇기에 `register`의 두번째 파라미터인 `options` 객체의 `deps` 배열에 `confirmPassword`를 넣어줍니다.

또 비밀번호를 위한 정규표현식과 그 정규표현식에 맞지 않을 때 뜰 에러메시지도 지정해줍니다.
기존에 `prop`으로 넘겨주었던 `name`, `value`, `onChange`를 넘겨줄 필요가 없게 되었습니다!

```jsx
// 비밀번호 확인 실패 에러메시지
<p>{errors?.confirmPassword}</p>
```

그리고 그 에러메시지는 `formState.errors.인풋name` 으로 사용하면 됩니다.

## 커스텀 밸리데이션

```jsx
    // 비밀번호 확인 인풋
    <PasswordInput
        // name='confirmPassword'
        // value={values.confirmPassword}
        // onChange={handleChange}
        {...register('confirmPassword', {
            validate: {
                sameAsPw: (v, formValues) => {
                    return formValues.password === v || '비밀번호와 비밀번호 확인 입력값이 일치하지 않습니다';
                },
                // 다른 커스텀 밸리데이션 규칙도 추가 가능!
            },
        })}
    />
```

정규표현식 말고도 커스텀 validation 규칙을 추가할 수 있습니다. 
위 코드에선 `sameAsPw`라는 이름의 validation 규칙이 있고, 폼의 `password`와 값 `v`가 같은지 확인합니다. 같지 않을 경우'*비밀번호와 비밀번호 확인 입력값이 일치하지 않습니다*'라는 에러 메시지가 표시됩니다. 

참고로 저는 이 에러메시지들을 상수화해놓고 따로 구현하였으나, 예시 코드의 가독성을 위해 직접 넣어주었습니다.

## 온클릭 submit 연동

마지막으로 아이디 중복확인 버튼을 클릭했을 때, 서버로 아이디 중복확인 요청을 날려 그 응답을 받아와야 합니다.
하지만 이런 경우 아이디 중복확인 버튼에 `type=submit`을 넣을 수는 없습니다. 폼의 최종 submit은 회원가입하기 버튼을 눌렀을 때 이뤄져야 하기 때문입니다.

```jsx
    // 아이디 중복확인 버튼
    <CheckIdBtn 
        onClick={handleSubmit(checkId)} // handleSubmit으로 연동
    >
        중복확인
    </CheckIdBtn>
```

```typescript
    const checkId: SubmitHandler<FormValues> = (data) => {
        console.log('입력한 id:' + data.userId) 
    }
```

이럴 때엔 `useForm`의 `handleSubmit` 메서드에 중복확인을 하는 함수 `checkId`를 인자로 넘겨주면 됩니다.
이렇게 하면 `checkId`는 `MouseEvent`가 아니라 react-hook-form에서 정의한 타입 `SubmitHandler`을 리턴하며 해당 폼에서 관리하는 `data`를 받아 사용할 수 있습니다.

이런 식으로 react-hook-form을 사용해 리액트에서 폼과 인풋을 간단하게 구현하고 관리할 수 있습니다.
직접 리액트 `state`로 폼 인풋의 `value`를 계속 추적하고 `onChange` 핸들러를 전해줄 필요가 없게 되었습니다. 

이렇게 react-hook-form을 직접 써보니 너무 좋아서 회사 프로젝트에도 도입을 했는데요! 
그 프로젝트에선 MUI의 `TextField` 컴포넌트를 공통화해 사용하고 있었는데요. 그 컴포넌트와 react-hook-form의 `FormContextProvider`, `useController`를 함께 사용하였습니다.
인풋을 동적으로 추가해야하는 부분에서는 `useFieldArray`를 유용하게 사용했구요!

그럼 이만 다들 react-hook-form을 사용해 즐거운 코딩하시길 바라겠습니다!
😁


리액트로 폼 구현할 때 onChange, value, 상태의 props drilling을 줄여봅시다.

react-hook-form으로 리액트 폼 개선하기


회사 프로젝트에서 리액트 쿼리(tanstack query)를 사용하고 있습니다. 
useMutation을 custom hook으로 감싸면서 좀 더 활용할 수 있는 방법을 찾아보다가 QueryClient를 사용해 
쿼리 캐시를 활용할 수 있는 방법을 생각해보았습니다.

## QueryClient

- Tanstack Query에서 제공하는 클라이언트 캐시에 접근할 수 있는 객체
- Query cache, mutation cache, logger 등과 연결되어있다.

### 용어

- staleTime: 데이터가 `fresh` 상태로 유지되는 시간. `fresh` 상태일 땐 쿼리 인스턴스가 새로 마운트되어도 fetch가 일어나지 않는다.
- cacheTime: `inactive` 상태인 캐시 데이터가 메모리에 남아있는 시간. 
쿼리 인스턴스가 unmount 되면 데이터는 `inactive` 상태로 변경되며, 캐시는 `cacheTime`만큼 유지된다.
`cacheTime`이 지나기 전에 쿼리 인스턴스가 다시 마운트 되면, 데이터를 fetch하는 동안 캐시 데이터를 보여준다.
- fetching, fresh, stale, inactive, delete

![Tanstack Query's lifecycle](https://github.com/pullingoff/nexthome/assets/50111853/8467b853-52c4-420a-9ee7-6a47d66fff04)

### 주요 메서드
- `fetchQuery({ queryKey, queryFn })`: fetch하고 쿼리를 캐시한다. (비동기)
쿼리가 존재하는데 데이터가 유효하지 않거나 staleTime을 넘어섰을 경우 캐시 데이터를 반환한다. 그렇지 않은 경우엔 최신 데이터를 fetch한다.
- `prefetchQuery({ queryKey, queryFn })`: 데이터가 필요하기 전에 쿼리를 미리 fetch한다.
`prefetchInfiniteQuery`도 있다.
- `getQueryData(queryKey)`: 해당 쿼리의, 캐시되어있던 데이터를 가져온다. (동기)
- `setQueryData(queryKey, updater)`: 동기적으로 캐시를 업데이트한다. 
cacheTime(기본값 5분) 이내에 쿼리를 사용하지 않을 경우 가비지컬렉트된다.
- `invalidateQueries({queryKey...})`: 캐시된 쿼리를 무효화하고 다시 fetch한다.

## 기본 refetch 조건
query가 refetch 되는 기본 조건은 아래와 같습니다. 공통화해두면 좋을 것 같습니다.

- `refetchOnMount`: 쿼리 인스턴스가 마운트될 때
- `refetchOnReconnect`: 네트워크가 다시 연결될 때
- `refetchOnWindowFocus`: 윈도우 창이 다시 포커스될 때 (개발자도구 클릭 후 돌아오는 경우 등)
- `refetchInterval`: 쿼리의 refetch Interval이 지나 refetch가 필요할 때

## 방법1: 리소스별 queryKey

![tanstack query keys](https://github.com/pullingoff/nexthome/assets/50111853/d22f276c-7431-4029-a9b7-cf9814314aaf)

쿼리 키는 캐시의 키다. 쿼리 키를 REST API처럼 리소스에 따라 나누면 한 캐시를 대상으로 CRUD 작업을 할 수 있다.

## 방법2: keepPreviousData

결과: 기존 데이터에서 새 데이터로 부드럽게 전환된다.

```js
type Filter = '전체' | '쿠팡' | '아임웹';

const useProductsQuery = (filter: Filter) =>
  useQuery({ 
    queryKey: ['products', filter], 
    queryFn: () => fetchProducts(filter) 
  });
```

위 코드는 filter 값에 따라 상품 목록을 불러오는 코드다. queryKey는 useEffect의 의존성 배열과 같은 존재다. 
그렇기에 filter 값이 바뀔 때마다 query Key가 변하고, query key가 변했으므로 쿼리가 refetch된다.

또 query key는 캐시의 키이므로, cache entry가 새로 생기고, 처음으로 필터를 전환할 경우 (로딩 스피너가 표시되는) 하드로딩 상태가 된다. 
이때 keepPreviousData를 true로 설정하거나 initialData를 설정해두면 새 쿼리가 새 데이터를 요청하는 동안 가장 최근의 데이터를 활용할 수 있다.

```js
export const useProductsQuery = (filter: Filter) =>
  useQuery({
    queryKey: ['products', filter],
    queryFn: () => fetchProducts(filter),
    initialData: () => {
      // '전체' 상품의 데이터를 활용해 우선적인 데이터를 보여줄 수 있다.
      const allProducts = queryClient.getQueryData<Products>(['products', '전체'])
      const filteredData =
        allProducts?.filter((product) => product.type === filter) ?? []
        
      return filteredData.length > 0 ? filteredData : undefined
    },
  })
```

이후 새 데이터가 도착하면 기존의 데이터가 부드럽게 새 데이터로 스왑된다. 
비슷하게 Tab에서도 각 탭의 query key를 다르게 해 사용할 수 있다.
다만 initialData를 쓸 경우 각 페이지에서 개발자가 추가해줘야하는 코드가 늘어날 수 있고, 
만약 기존 데이터 중 filter에 걸리는 데이터가 없다면 보여줄 데이터가 없을 수도 있다. 이런 경우엔 전체 데이터를 보여줘야할 것이다.

## 방법3: Smart refetching

결과: mutation이 성공할 때마다 매번 refetch 되는 것이 아니라, 데이터가 필요할 때 fresh하게 불러오도록 한다.

상품 목록에서 한 가지 상품을 골라 삭제를 할 수 있다. 
상품 삭제 모달에서 confirm을 하면 상품 목록이 리렌더되며 해당 상품이 제외된 상품 목록이 표시되어야한다. 

이렇게 CRUD 후 바로 적용된 데이터를 보여줘야 할 때, mutation success callback에서 관련된 쿼리의 캐시를 무효화시킨다. 
데이터를 invalid시킴으로써 React query가 해당 쿼리를 refetch를 하도록 만드는 것이다. 

```js
 // 상품을 삭제한다.
  const deleteProduct = (productId) => {
    return axios.delete('/product', productId);
  };
  
  const { mutate: deleteProduct } = useMutation(deleteProduct, {
    onSuccess: () => {
      // 방법1. queryKey가 'products'로 시작하는 모든 쿼리 무효화
      queryClient.invalidateQueries('products');
      
      // 방법2. productId에 따라 해당 쿼리 무효화 
      queryClient.invalidateQueries({ queryKey: ['products', productId] }
    }
  });
```

`onSuccess` 안에서 `invalidateQueries`로 쿼리를 무효화시켜 refetch하도록 하는 것과 `refetch()`를 직접 호출하는 것에는 차이가 있다. 
직접 refetch를 할 경우 요청을 새로 보내서 데이터를 새로 가져오게 된다. 
해당 쿼리를 보고 있는 observer가 없어도 무조건 다시 가져온다. 
반면 invalidateQueries를 사용하여 데이터를 무효화하는 경우 데이터는 `stale` 상태로 변했다가
이후 query의 refetch 조건에 부합할 때에 fetch하게 된다. (useQuery 나 관련 훅을 통해 쿼리가 렌더링되고 있다면 백그라운드에서도 refetch한다.)

refetch를 하면 query key(예를 들면 무한스크롤 컴포넌트의 page)를 기준으로 inactive한 모든 페이지의 데이터를 불러오지만 
쿼리 무효화를 하면 우선 query를 `stale`하게만 만들기 때문에 `active`한 페이지의 데이터만 fetch한다. 이러한 이유로
쿼리 무효화를 하는 게 미세하게 나은 성능을 가질 수 있다.

`setQueryData`를 통해 optimistic update를 하는 방법도 있지만,
변화를 우선적으로 적용한 뒤 성공 여부에 따라 값을 다시 바꿔야하는 optimistic update보다는 무효화를 하는게 
각 쿼리에서 개발자가 추가해야할 코드의 양은 적어지는 것 같다.

## 참고 

- [Practical React Query](https://tkdodo.eu/blog/practical-react-query#treat-the-query-key-like-a-dependency-array)
- [React Query로 서버 상태 관리하기](https://blog.rhostem.com/posts/2021-02-01T00:00:00.000Z)
- [refetch vs invalidating query](https://github.com/TanStack/query/discussions/2468)


Tanstack query useQueryClient로 할 수 있는 일들

Tanstack Query 캐시 활용하기 (리액트 쿼리 QueryClient)


## 요즘의 아쉬움

문득 든 생각인데 최근 3개월은 기술적으로 나아진 게 없는 거 같다.
정산 어드민 리뉴얼 프로젝트를 열심히 했는데, 하루 8시간 주 5일 회사에서 뇌 리소스를 다 써버리니까 주말이나 퇴근 후엔 거의 개발을 못했다.
사이드프로젝트(리욜드) 개발을 하긴 했지만 짜는 코드의 질은 별로 개선이 없었던 느낌이랄까?

지난 12월 말 - 1월 초에 코로나 휴가를 가지면서 유인동 강사님의 인프런 함수형 강의를 들었다.
잘 써먹어보리라 다짐했었는데 아직 실제 프로젝트에서는 못 써봤고, 주중에 시간을 따로 내서 하는 동료들과의 스터디와
개인 사이드 프로젝트만 간간히 하고 있다.

작년 하반기에는 레거시 홈페이지의 자동화 테스트를 도입했다. Cypress, Mocha 문법, POM 패턴, 테스트 코드 짜는 법 등등
공부하면서 실무에서 사용해볼 수 있었는데 최근 3개월에는 프로젝트 완성을 최우선으로 하느라
문서를 그때그때 발췌독하면서 작업을 해서 이런 아쉬움이 남았다.(이런 작업 방법이 나쁘다고 생각하지는 않는다.)

어쨌든 회사 내 성과 평가는 잘 받았지만 뭔가 채워지지 않는 것이 있었다고나 할까.
진짜 일을 잘 하는 사람들은 회사를 위해 일하지 않고 나를 위해 일한다던데
최근 몇개월간은 내 개인적 성장보다는 회사를 위해서 일한 것 같다.

물론 그 과정에서 내가 기존에 사용해온 기술들을 더 잘 이해할 수 있었고, 더 많은 문서와 지식을 얻긴 했지만
지금보다 더 라이브러리를 잘 활용하고, 코드의 질도 높이고 싶다. 기술 부채를 청산할 때가 온 거다.
그래서 이런 고민을 한 팀 동료에게 이야기했는데 같이 정기적으로 회고해보자고 하셔서 매주 금요일마다 해보려고 한다.

또 블로그 글의 질을 높이고 싶다. 그냥 기본적인 개념을 정리해놓기보단 정말로 내가 개발하면서 마주쳤던 문제와 내가 찾은 해결법, 시도들을 
기록하고 싶은데 그런 글을 쓰려면 품이 많이 든다. 틈틈이 내가 썼던 글들을 보면서 보완하거나, 글 목록에서 빼두려고 한다. 
이미 같은 고민을 먼저 했던 사람이 더 나은 해결책을 적어두진 않았을까 싶어서 쓰는게 주저되기도 한다.    
쉽지 않군

## 회고 양식

**[new]**
- 이번주 새로 배운 것이 있었나요?
- 있었다면, 다음번에 또 활용할 수 있을까요? 어떻게 활용하면 좋을까요?

**[finding]**
- 이번주 기술적으로 가장 어려웠던 건 뭐였나요? 어떤 이슈가 있었나요?
- 해결했다면 어떻게 해결했나요?

**[future]**
- 앞으로 시도해보고 싶은 게 있나요?

## 3월 돌아보기

### [new] 새로 배운 것이 있었나요?

- Mui ver.4에는 `warning`, `info`, `success` 등의 color prop이 없다.
- **행복 방정식**. 행복은 내가 원하는 것 대비 내가 가진 것의 양이라는 방정식인데,   
  이때 행복을 키우는 방법에 분모를 줄이는 것 또는 분자를 키우는 것이 있다면 나는 분자를 키워 행복을 키우려는 사람이다.  
  왜 그렇냐면 타고난 성정이 '새로운 뭔가를 해보는 것'을 너무 좋아해서 그렇다.
  활기와 에너지를 갖고 다양한 것에 도전하며 분자를 늘리려 노력하자.
  
<img width="200px" alt="행복 방정식" src="https://user-images.githubusercontent.com/50111853/227767505-853dc3ee-1c17-4be7-9aa3-29cb818c0509.png"/>

### [finding] 가장 어려웠던 건 뭐였나요?

알림처럼, 숫자 뱃지가 위에 올라가는 탭. Mui Tab 컴포넌트와 Badge 컴포넌트를 썼는데 탭도 `span`, 뱃지도 `span`이라 `width` 잡기가 힘들었다.
글자 수에 따라 다이나믹하게 탭 길이가 달라지는 걸 원했다. 탭의 `overflow: hidden` 속성들을 다 `visible`로 바꾸고
글자 수가 가장 적을 경우를 `min-width`로 고정해둬 글자수가 길어지더라도 글자와 뱃지가 모두 보이도록 했다.

### [future] 앞으로 시도해보고 싶은 게 있나요?

react-query 더 자세히 공부


2023년 3월 요즘의 생각


자바스크립트 ES6에서 배열은 프로토타입 메서드 map, filter, reduce를 가진다.
배열이 아니더라도 이터러블이라면 사용할 수 있는 함수형 map, filter, reduce 함수를 구현해본다.

## map

수집할 값 정보를 파라미터 함수 `f`에게 완전히 위임한 고차함수 map을 구현해보자.
이터러블을 순회하며 함수 `f`를 실행한 값을 배열에 넣어 리턴하도록 하면 된다.

```js
const map = (f, iter) => {
	let res = [];
	for (const a of iter) {
		res.push(f(a));
	}
	return res;
}

map(p => p.name, products)
map(p => p.price, products)
```

## 이터러블 프로토콜을 따른 map의 다형성

```js
document.querySelectorAll('*').map(el => el.nodeName);
```

위 코드에서 `querySelectorAll`의 리턴값인 `NodeList`는 배열을 상속받지 않았기 때문에
map 함수가 없다고 뜨고, 에러가 뜬다. 그럴 땐 위에서 정의한 map 함수를 쓰면 된다.

```js
map(el => el.nodeName, document.querySelectorAll('*'));
```

제너레이터가 반환하는 이터레이터를 순회하는 것도 가능하다.

```js
function *gen() {
	yield 2;
	if (false) yield 3;
	yield 4;
}

map(a => a*a, gen());
```

최근 ECMAScript의 헬퍼 함수들이 이터러블 프로토콜을 기반으로 만들어지고 있어 앞으로 호환성도 좋아질 예정이다.

### 자료구조 Map 써보기

기존의 `Map` 자료구조를 사용해 새로운 map을 만들 수도 있다.

```js
let m = new Map();
m.set('a', 10);
m.set('b', 20);

new Map(map(([k,v] => [k, v*2]), m));
```

## filter

이터러블에서 조건에 맞는 원소만 걸러내는 함수형 `filter`를 만들어본다.
전체적인 구현 방식은 `map`과 비슷한데, `f(a)`가 `true`인 값만 걸러내면 된다.

```jsx
const filter = (f, iter) => {
	let result = [];
	for (const a of iter) {
		if(f(a)) result.push(a)
	}

	return result;
}
filter(p => p.price > 3000, products);
```

## reduce

reduce는 **값을 순회하면서 하나의 값으로 누적해 축약**하는 함수이다.
reduce는 영어로 '졸이다'는 뜻도 있는데, 여러개의 값을 졸여서(누적해서) 하나의 결과값을 생성한다고 생각하면 이해가 편하다.
이 함수는 **보조함수(1번째 파라미터)에 어떻게 축약할지를 완전히 위임**한다.

배열의 모든 원소를 더하고 싶을 때 `reduce`를 쓰지 않고 구현한다면 아래와 같다.

```js
const nums = [1,2,3,4,5]

let total = 0;
for(const n of nums) {
	total += n;
}
```

이제 `reduce`를 사용해 리팩토링해보자.
자바스크립트 내장 `reduce`에서는 `acc`를 생략할 수도 있으니 만약 `acc`가 생략되었다면 자동으로 첫번째 요소를
두번째 파라미터를 기본값으로 변환하도록 한다.

```js
reduce(add, 0, [1,2,3,4,5]); // 15
// =(add(add(add([0,1]), 2), 3).... 을 반복하는 것임

const add = (a, b) => a+b;

reduce(add, [1,2,3,4,5]);   // 이렇게 온다면 자동으로
reduce(add, 1, [2,3,4,5]);  // 첫번째 요소를 기본값으로 변환해 계산한다.

const reduce = (f, acc, iter) => {
	if(!iter) {
		iter = acc[Symbol.iterator]();
		acc = iter.next().value;
	}
	for (const a of iter) {
		acc = f(acc, a)
	}
	return acc;
};
```

커스텀한 `reduce` 함수는 가장 먼저 3번째 파라미터(이터레이터)가 있는지 확인하고, 없을 경우
`acc`에서 자기 자신 이터레이터를 꺼내오고, 그 `이터레이터.next()`의 값을 `acc`로 지정한다.

### reduce로 products의 모든 가격을 더한다면

```jsx
reduce((total, curr) => total + curr.price, 0, products)
```

## map+filter+reduce 중첩 사용과 함수형 사고

1. `map`으로 가격을 뽑는다
2. `filter`로 특정 금액(3만원) 이하의 상품만
3. `reduce`로 모든 가격의 합을 구한다

이 때 `filter`, `map`의 순서를 바꿔도 결과는 동일하다.

```js
const add = (a, b) => a+b;
	reduce(
		add,
		map(p => p.price,
			filter(p => p < 30000, products)
	)
)
```

좀 더 함수형으로 생각하려면 `add` 다음 파라미터(`curr`)나 `map`의 두번째 파라미터(타겟 arr)가 숫자가 있는 배열로 평가되도록 코드를 작성하면 된다.

```js
reduce(
	add,
	// 숫자 배열로 평가되도록
)
```

*참고: 인프런 [함수형 프로그래밍과 Javascript ES6+](https://www.inflearn.com/course/functional-es6)*

배열이 아니어도 사용할 수 있는 map, filter, reduce 함수형으로 만들어보기

Recent Posts