FrontEngineer JungBam

현업 개발자들과 이야기를 하다가보면 next.js 13이 좋지만 아직 안정화되어 있지 않고 계속해서 업데이트가 진행되다보니 변동사항이 생긴다. 오늘 그 말을 실감했다..(develop 단계에서 아무런 에러도 없다가 배포를 하고 production 단계에서 좌측 사진과 같은 에러가 발생했다.) 결론은 클라이언트 사이드에서 예외가 발생했으니 콘솔을 봐라. 콘솔을 봤더니 우측사진과 같은 모양이었다. 무슨 해괴망측한 소리인가 봤다. 단지, 유추할 수 있었던 것은 production 단계에서 발생하는 에러들이라는 점. 배포는 버셀로 했기 때문에 배포단계에서의 문제는 아니라고 생각을 했고 next.js 에서 이런 에러가 발생하는지를 찾아봤다. 일단 production 단계 확인을 위해 build 후 실행을 했는데...

코딩을 하다가 이런 에러를 만났다. 찾아보니 'prop-type'이라는 타입을 검사하는 내부 동작때문이라고 하는데 왜 그런지 어떻게 해결할 수 있는지를 알아보자. React.ComponentType과 React.FC에 대해서 알고 있다면 이런 궁금증이 생길것이다. 내부적으로 props에 대한 타입 검사를 하도록 동작하는 React.FC로 설정한다면 어떻게 될까?? 바로 사라지는 것을 알 수 있다. 하지만, 지난번에 봤다싶이 React.FC와 React.ComponentType은 동작방식이 다르고 React.FC는 암묵적으로 children을 포함시키는 부분 때문에 React.ComponentType이 조금 더 사용하기에 좋다는 점을 알고 있다. 그럼 React.ComponentType을 유지한 상태에서는..

처음 무한스크롤을 구현한 1년 전보다 개념적으로도 실력적으로도 많이 늘었구나 싶다. react query의 useInfiniteQuery를 활용해서 무한스크롤을 만드는데에 있어 이전에는 불필요하게 파생상태들이 각각의 상태값으로 관리되어 불필요한 리렌더링을 가져왔고 이번에 만들때에는 그런 부분이 없도록 만드려고 노력했고 그 부분이 눈에 띄게 비교가 되어서 만족스럽다 ㅎㅎ 그 중 fetchNextPage 함수를 실행시키기 위해서 intersection observer API 를 사용하기로 했다. 이 부분에서도 이전과는 달리 해당 UI 컴포넌트에 기능을 덕지덕지 붙이는 것이 아니라 로직만 별도 분리해서 컴포넌트로 만들었는데 깔끔하게 동작이 되어서 참 좋다. 만들면서 식별자도 신경을 많이 썼다. 누가봐도 알 수..

카테고리를 추가하는 기능을 만드는 과정에서의 이슈 영어를 치면 정상 작동하지만 한글을 작성하면 끝음에 대해서 한번 더 처리하는 문제가 발생! 왜그럴까? (그 증상과 문제를 만났을 때의 코드) 그래서 이 부분에서 왜 이런지 콘솔을 찍어보니, 이상하게도 한글을 치고 엔터를 누르면 두번의 이벤트가 들어오고, 영어를 치고 엔터를 누르면 한번의 이벤트가 들어오는 것을 확인할 수 있었다. 그래서 이것을 어떤방법으로 다가가야 내가 필요한 곳에서 처리가 가능할지를 찾아보다가 한글의 경우에 두개 이상의 글자가 조합을 통해 하나의 글자가 되는데 이러한 것을 잡을 수 있는 이벤트가 있었다. (예를 들어, 말라 라고 쳐도 한글의 경우에는 아직 입력중으로 받아들인다. 말라 가 말락이 될지 말랏이 될지 모르기 때문에) 바로, e..

제어 컴포넌트와 비제어 컴포넌트는 각각 장단점이 있는 방식이다. 그런데 React 팀에서는 제어 컴포넌트를 권장한다.(공식문서에 명시되어 있음.) 오늘은 왜 그런지 다시한번 상기해보는 시간! React에서는 상태값이라는 값을 통해 가상돔에서 어떤 노드리스트를 수정할 것인가를 체크한다. 또한 리렌더링 없이 DOM요소에 접근하는 useRef를 통한 비제어 컴포넌트도 지원한다. 지원하는데에는 이유가 있을 것이고, 각각 사용하는 곳을 선택하는 근거가 있을텐데 어떤 점들이 있는지 알아보자. 먼저 각 방식에 있어 장, 단점을 알아보고 넘어가자. 구 분 장점 단점 제어 컴포넌트 1. 상태가 React 컴포넌트 내에 있으므로 입력 데이터를 직접 조작하거나 검증하는 것이 쉽다. 2. React의 "single sourc..

서버에서 요청받는 값들을 타입을 지정해서 작업한다면 DX적으로 얼마나 편리할까? 자동완성이라던가, 다른 타입에러들이 없을텐데.. 타입스크립트를 사용하면서 이런 생각들을 해봤을 것이다. 타입 스크립트로 개발하면서 하나하나 타입을 지정하고 작업하는 것이 당연해질때즈음이면 자동완성이 뜨지 않으면 뭔가 지정하고 싶은 욕망이 생긴다. 어떻게 할 수 있을까? 제네릭 타입을 사용하는 경우의 대표적인 케이스가 이 경우가 아닐까 생각이 든다. 아래 코드를 보면 instance(axios client)를 통해서 넘어오는 값의 타입을 명시적으로 detailPost로 지정해준 모습이다. getDetail: async (id: number) => { return await instance.get(`/api/post?id=${i..

프로필 사진을 수정하는 컴포넌트의 테스트 코드를 작성하던 중 만난 에러 먼저 일반적인 input file 타입에 파일을 업로드하는 테스트 코드를 보자. 간단하게 넣어줄 이미지 파일을 만들어주고 useEvent를 통해 input에 넣어준다. 그리고 input에 입력된 사진이 Image 태그에 들어가는지 테스트하는 코드이다. 근데 56번째 줄을 보면 base64형식의 string 데이터가 보이는데, 저 부분이 바로 오늘 이야기하고자 하는 부분이다.(결론은 저렇게 짜야 테스트 코드가 동작한다는 것!) 아래는 내가 처음 만난 에러화면인데 목 파일로 만들어준 이미지 파일이 들어갔을 것으로 예상했지만 base64로 변환된 데이터가 들어가면서 예상과 다른 값이 들어가있다고 스티커가 붙은 부분에서 이야기를 해주고 있다..

next.js에서 private route 만들기 어느 페이지에 들어가려고 할때 로그인 된 경우에만 들어갈 수 있도록 하고 싶다... 라는 생각으로 React에서도 private route를 Router 컴포넌트에 만들어줬었는데 next.js에서도 동일한 기능을 하는 HOC infomationjunk.tistory.com 위의 글에서 만든 private route에서 props가 있는 컴포넌트를 감싸면 어떻게 될까? 바로 에러가 발생한다. 말 그대로 param를 받도록 타입이 잡혀있지 않기 때문이다. 타입이 잡혀있지 않다? 바로 이부분이다. 타입 지정에 문제가 없는 것 같아보이지만, HOC에서 반환하는 경우 기본적으로 props가 있을 수도 없을 수도 있는데 이 React.FC라는 타입은 기본적으로 ch..