FrontEngineer JungBam

프로필 사진을 수정하는 컴포넌트의 테스트 코드를 작성하던 중 만난 에러 먼저 일반적인 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..

position - CSS: Cascading Style Sheets | MDN CSS position 속성은 문서 상에 요소를 배치하는 방법을 지정합니다. top (en-US), right (en-US), bottom (en-US), left (en-US) 속성이 요소를 배치할 최종 위치를 결정합니다. developer.mozilla.org 기본적인 내용은 위의 링크를 통해 이해하기 바라고 오늘 다뤄볼 내용은 sticky로 사이드바를 만들면서 겪었던 이슈와 그 해결방법에 대해서 다뤄볼 생각이다. 문제상황 : sticky를 통해 사이드바를 구현하고 sticky가 정상 동작하였지만, 디자인 수정으로 푸터를 추가하고 나니 내려가다가 footer 컴포넌트의 영역을 침범하는 이슈가 발생함.(아래 그림 참고) s..

기본적인 CI/CD의 설명이 필요하다면 아래 링크를 통해 CI/CD에 대해서 알압보고 글을 읽으면 좋을 것 같다. CI/CD(CI CD, 지속적 통합/지속적 배포): 개념, 툴, 구축, 차이 CI/CD는 애플리케이션의 통합 및 테스트 단계부터 제공 및 배포까지 애플리케이션 라이프사이클 전체에서 지속적인 자동화와 지속적인 모니터링을 제공하는 것을 뜻합니다. www.redhat.com 깃헙 액션을 활용하는 것은 이전에 gpt를 통한 코드리뷰 이후 두번째인데 이번에는 깃헙 액션을 통한 CI 파이프라인을 설정하는 방법에 대해서 알아보자. CI파이프 라인이라는 것은 지속적 통합을 의미하는 것으로 ' BUILD > TEST > MERGE ' 의 워크플로우를 의미한다. 왜 필요한지에 대해서는 테스트 코드를 작성한 사..

음성 인식을 위해 비동기적 처리가 되어있는 패키지를 사용하려고 하던 중 만난 에러 아래의 에러메세지에서 알 수 있듯이 원인은 regeneratorRuntime을 찾지 못하는 것인데 먼저 이 regeneratorRuntime은 어떤 친구인지부터 알아보자. 먼저, async/await은 비동기를 처리하는 것은 다들 알고 있을것이다.(모른다면 이전 글에서 찾아보면 정리한 글이 있다.) 하지만 이 async/await은 ES6 문법, 비교적 최신의 문법이고 구형 브라우저나 이전의 코드에서는 동작하지 않게 될 것 이다. 이를 해결하기 위한 것이 바로 Babel에서 런타임에서 실행시키는 regeneratorRuntime 이라는 친구인 것이다. 왜인지를 아는 것이 중요한 것은 어느 부분을 수정해서 에러를 잡을 수 있..

Headless CMS가 과연 어떤 것인지 알아보자. Headless CMS는 콘텐츠 관리 시스템인 백엔드와 클라이언트측 애플리케이션인 프론트엔드를 분리하는 오늘날의 웹 디자인을 위한 관리 시스템이다. 따라서 Headless CMS는 (프론트엔드) 애플리케이션이 해당 콘텐츠에 액세스할 수 있도록 하는 메커니즘과 함께 (백엔드) 콘텐츠 관리 서비스를 담당한다. 기존 콘텐츠 관리 시스템은 프론트엔드와 백엔드가 분리되어 있지 않았기 때문에 최신 프론트엔드 기술스택을 통해 접근하기 어려움이 있었으나, 프론트엔드와 백엔드의 분리로 인하여 프론트엔드에 영향을 받지 않기 때문에 내가 개발하고 싶은 기술스택을 통해 프론트엔드를 개발할 수 있도록 된 것이다. CMS에 대한 기본 지식을 더 얻기 원한다면 아래 링크로 가서..

흔히들 사용하는 방법으로 두가지 방법이 있을 수 있다. 1. Socket 통신을 사용하여 지속 연결된 상태에서 변경이 발생할 때에 이벤트를 프론트에 보내주는 방법 2. SSE(server sent event)를 통해서 서버에서 이벤트가 발생했을 때에 프론트가 이벤트를 받는 방법 socket과 sse의 차이점은 socket통신 자체는 양방향 통신이 가능하다는 것이고 sse는 서버에서 클라이언트로 보내주는 단방향 방식이라는 점이다. 양방향 통신을 유지하기 위해서 서버도 클라이언트의 이벤트를 듣기 위해 동작을 해야하는데, 알림과 같은 기능일 경우에는 서버에서 클라이언트에게만 제공하면되기 때문에 양방향으로 구현하기보다 단방향으로 구현하는 것이 더 탁월한 선택입니다. 프론트에서의 SSE 구현 간략히 설명하면 Ev..

티스토리 오픈 API를 활용하여 게시글에 대한 데이터베이스로 활용하는 경우 백엔드 개발자와 함께 오픈 API를 DB로 활용하기 => 서버에서 해당 글 id에 대해서 유저와 매칭을 하고 매칭된 티스토리 글 id값을 기억했다가 보내주는 방식으로 구현 가능 1. 글을 작성했을 때 넘어오는 response값에서 postId를 그 글의 id로 유저테이블에 매칭해서 저장 { "tistory":{ "status":"200", "postId":"1", "url":"http://informationjunk.tistory.com/1" } }​ 2. 프론트에서 해당 글에 대한 정보를 요청하면 서버에서 티스토리 API를 활용하여 티스토리에서 글에 대한 정보를 가져옴. 아래가 티스토리 API에서 글 내용을 가져왔을 때의 값이면..