usecallback, usememo
- 요즘에는 안쓰는게 트랜드인 것 같다.
- 필요할 때만 쓰는 것이 좋다. (usememo는 거의 쓸 일이 없다.)
- 메모리가 부족해서 뻣는 경우가 있다. -> 리스트가 많을 경우. usememo도 메모리를 먹음.
usememo를 사용하는 경우- 가상리스트, lazy로딩처리
프로젝트 코드와 리뷰 관련
- input, button들에 form을 사용하는 것이 좋다.
- 장점1. 시멘틱하게 보여줄 수 있다. - 확실하게 제공(접근성good)
- 장점2. form에 require, maxlength, minlength -> native하게 처리할 수 있다. (variants한 부분 들이 많이 들어갔다.)
- button에서 border가 타입이 다양하다면, 준혁님처럼 처리하는 것이 좋을 수 있다. 아니라면, 성민님처럼 처리하는 것이 좋을 수 있다.
- Q. 기본적으로 tailwind 테마를 등록해서, gap이나 size같은 경우에 지정을 해두고 사용을 하기로 했다. 그런데 이 방법은 유동성이 크고, variants를 사용하는 것이 퇴색되는 것 같다 - 고민
- 디자인시스템을 만든다면 -> 제한된 자유도
- Q. 개발 시간 부족이 걱정되는데, 효율적으로 진행할 수 있는 방법?
- case변환같은것, api, 공통 된 것 -> 손 빠른 한 명이 하는 것도 좋다. 편하다.
- 미리 이슈를 다 따놓는 것도 좋다.
- mock서비스 워커 사용하는 것도 좋다.
- 다양한 케이스를 만드는 것 고통스럽다. api스팩은 협의 하면서 진행하는데.. page를 만들 다보면, api를 쪼개야하거나 하는 경우가 있다. api가 만들어진 후에 이런 것들을 수정하려면 힘들다.
- Nock, JSON Server, Mirage와 비교를 해놨다. -> 모두 Mock이라는 라이브러리를 사용 mock환경을 제공해줄 수 있는 라이브러리가 많다. msw가 제일 좋다. = Mock Service Worker
- page개발을 할 때는 모두 storybook에 붙이지 않는 경우가 있다. -> mock이용 good 이런 처리 다 해놓으면 엄청 편하다.
- 시간이 없으면 발생되는 이슈들
- 날 것의 커밋 - 그래도 정리된 커밋을 올려야 된다.
- 포폴로 사용할 것이라면 - 덮어놓지 말고, 커밋을 정리해도 좋을 것 같다.
- 뒤로 가더라도 커밋 메세지 잘 작성하기
- PR도 잘 올리기
- 머지하기 전에 잘 정리하는 것이 좋다.
- api는 프로젝트 전체를 총괄하는 느낌이여서, common에 두는 것은 어떤가. 나중에 구분이 될 여지가 있고..
네이버 뉴스레터 읽기
- npm malware - 최소한의 방지
- event-stream npm 라이브러리 - 더이상 유지보수 못해요. 해커가 받아가서, github에는 안올리고 build에만 넣어놔서 해킹
- load balancing - 어떻게 서버의 http 요청을 분산할지.
- Q. styleX도 많이 사용할 것 같나요?
- 너무 성숙한 친구들이 많다.
- meta가 주도하는 FE트랜드가 끝이 날 것이라 생각한다.
- recoil, vercel을 오히려 많이 사용한다.
- vercel의 시대가 오지 않을까.
