FrontEngineer JungBam

보호되어 있는 글입니다.

주식이나 투자와 같은 서비스에서 딱 제일 먼저 생각나는 부분은 그래프! 그래서 대기업에서의 프론트들은 이 데이터들을 어떤식으로 그래프를 그리는지 궁금했다. canvas로 그리는 것은 해봤지만 각각의 값을 모두 canvas에 그려주는 것은 비효율적일 것이라 생각하던 중에 문득, 대기업은 어떤식으로 구현하는지가 궁금했다.  ㅇㅇ 사이트에 들어가서 확인해보니 svg의 path data를 토대로 그래프를 그려주는 것을 확인할 수 있었고, 한번 만들어보자. 라는 생각이 들었다. 이 데이터의 값을 백엔드에서 받는다고 가정하고 svg로 그래프를 만드는 것을 해봤다. 간단하게 데이터를 넣어서 그려주는것은 간단했다. L, M 값을 통해서 그려주면 되는 것이었기 때문에. (L : Line To, 현재 위치에서 지정한 위..

문제 상황 : CKEditor를 통해 에디터 기능을 구현하는 중에 기존에 동적 경로로 이동중이던 페이지를 정적 경로로 변경하고 나서 발생한 에러 next.js 자체에서 해당 에러에 대한 해결방법으로 던져준 페이지는 아래 링크와 같다. next.js에서 제시한 방법을 실행하던 중 찾은 답에 대한 정리글이다. Prerender Error Using App Router Features available in /app nextjs.org 원인 분석 : - Link 를 통한 prefetching 진행 중에 서버에서 브라우저 전용 컴포넌트가 렌더링되면서 발생 해결 방법 : - Link 속성 중 prefetch 속성을 false로 부여 - dynamic을 동한 동적 임포트로 서버 사이드에서 렌더링되지 않도록 설정 c..

현업 개발자들과 이야기를 하다가보면 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..

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