FrontEnd

프론트엔드 개발자는 백엔드 개발자들이 구현해놓은 api를 호출하여 얻은 데이터를 UI에 띄워주곤 한다.아마 대부분의 경우 GET method를 통해 데이터를 얻어올 것이다. 불러오는 데이터의 양이 그리 많지 않다면 큰 문제는 없을 것이지만, 만약 불러와야 할 데이터의 양이 매우 크면 문제가 생기게 된다.사용자는 어쩌면 데이터를 확인하기 위해 많은 시간을 기다려야 할 수도있다.데이터에 이미지가 포함되어 있다면 그 시간은 엄청나게 늘어날 것이다! 이를 방지하기 위해 무한 스크롤은 프론트엔드에서 필수적인 기술이라고 할 수 있다. 무한 스크롤이란? 말 그대로 무한으로 스크롤되게 만드는 기법을 뜻한다.무한으로 스크롤이 된다는 것은, 보여줄 데이터가 아직 남아있음을 뜻한다.즉 한번에 모든 데이터를 불러오는 것이 아..

강의의 마지막 세션에서는 현업에서 테스트코드라는 주제를 다루었다.현업에서는 다양한 도구들을 활용하여 테스트코드를 작성하고 있는 것 같았다. Cypress Cloud Cypress Cloud는 Cypress에서 무료로 제공해주는 클라우드 서비스이다.Cypress에 로그인만 하면 Cypress Cloud에 접근할 수 있다. 여러 단계를 거쳐서 로그인을 한 후 프로젝트를 하나 생성해주면  위와 같이 프로젝트 ID를 발급받을 수 있다.이 ID를 cypress.config.ts 파일에 명시해주면 된다. export default defineConfig({ projectId: "발급받은 프로젝트 ID", e2e: { setupNodeEvents(on, config) { // implement no..

이전 블로그에서 효율적인 협업을 위해서는 git commit을 깔끔히 관리하는 것이 중요하다고 느껴 git merge에 대해 자세히 알아보고, 상황별 적합한 merge 방법에 대해 알아보았다.협업에서 또 가장 중요한 것이 팀원들과 정해나가는 컨벤션이라고 생각한다. 협업 과정에서는 수많은 컨벤션을 정해 나가야한다.PR및 commit의 단위, commit 메시지 형식, PR 형식, 폴더 및 파일 구조 등 통일해야 할 것이 너무나도 많다.디프만 프로젝트에서 채택한 협업구조를 간략하게 정리해보려고 한다.기본적인 세팅은 Next 14(CNA)의 디폴트 세팅부터 시작한다. ESLint ESLint는 협업 상황에서 코드의 일관성을 유지시켜주고, 잠재적인 에러를 잡아주는 역할을 한다.예를 들어, 사람마다 arrow f..

이전까지는 혼자, 혹은 둘이서만 프론트 프로젝트를 진행하거나 / 다수로 진행하더라도 촉박한 기간으로 인해 협업을 위한 컨벤션 정하기 및 세팅에 소홀했었던 것 같다.이번에 디프만 프로젝트를 진행하면서 협업에 더욱 신경써야할 것 같았고, 이를 위해 효율적인 협업을 위한 세팅을 진행해보고 Git 복습도 진행하기로 했다. Merge / Squash & Merge / Rebase & Merge 나는 지금껏 일반적인 Merge만 사용해왔었다.그런데 Merge에도 여러 종류가 있고, 팀의 컨벤션에 맞게 적절한 Merge 방안을 선택한다면 수많은 commit들을 더욱 효율적으로 관리할 수 있을 것 같았다. PR을 날린 후 Merge에 종류를 보면  위처럼 3가지의 merge 방식 중 하나를 택할 수 있다.그럼 각 방식..

이전 블로그에서는 Jest와 MSW를 이용하여 회원가입 테스트를 진행해보았다.이제는 E2E 테스트의 대표적 선두주자인 Cypress로 회원가입 E2E 테스트를 진행해보기로 했다. Cypress 설치 yarn add -D cypress 그 어느 패키지와 마찬가지로 위 명령어를 통해 설치를 시도했다.근데 위 명령어로 설치를 하고 cypress를 구동하면 계속 No version of cypress is installed 라는 에러가 떴다.나는 프로젝트에서 Next 14와 Typescript v5를 사용하고 있는데 호환이 안되는 것 같았다. 구글링 결과 ./node_modules/.bin/cypress install 위 명령어를 통해 cypress의 바이너리 파일을 다운로드 해주면 문제를 해결할 수 있다고 했..

컴포넌트들이 모여 어떠한 하나의 기능을 수행할 때, 서버 통신이 개입되는 경우가 많다. 이 때, 만약 백엔드 단에서 api가 덜 만들어졌거나 원하는 결과를 넘겨주지 않는다면 먼저 프론트 개발을 들어가기도 어렵고, 완성되지 않은 api를 요구하는 기능의 테스트를 건너뛸 수 밖에 없다.결국 서버 통신이 요구되는 어떠한 기능이 잘 돌아가는지 보장할 수도 없고, 추후에 추가하더라도 이미 다른 코드들이 많이 짜여져있는 상황인데 이 기능의 예상치 못한 버그로 인해 많은 코드를 고쳐야할 수도 있다. 이러한 상황을 방지하기 위해 nock과 같은 라이브러리도 있지만, 나는 MSW를 도입하기로 하였다. MSW란?  MSW는 API 요청을 가로채서 사전에 설정해둔 목업 데이터를 넘겨주도록 설정해 주는 도구이다.nock과 같..