프로젝트

Redux-Thunk에서 React-Query와 Redux에서 Zustand로의 전환 1. 서론 2주차 동안 예상치 못한 이벤트가 많아 우선순위에 따라 일정 조정을 하다 보니 회고를 작성하지 못했다. 그러나 그 동안 인자강 프로젝트의 본격적인 리팩토링을 진행했다.

기존에는 CSR(Client-Side Rendering) 방식으로 게시판을 구현했다. 이 방식은 클라이언트에서 모든 데이터를 가져와 렌더링하는 구조로, 초기 로딩 속도가 느리다는 단점이 있다. 하지만 데모 서비스의 특성상 많은 데이터를 경험하기에는 역부족이었다. 500

프로젝트 초기에는 ESLint가 무엇인지 정확히 몰랐다. 그냥 기본적으로 설정해야 하는 거라 큰 의미 없이 셋업을 했기 때문이다. 결과적으로 ESLint를 제대로 활용하지 못하고 있었다. eslint --fix --ext .js,.jsx,.ts,.tsx. 명령어를 실행

리팩토링 사항을 모두 적용한 후, 성공적으로 Vercel 빌드 액션을 통과하여 배포를 완료했다. 로컬 환경에서 별다른 문제 없이 잘 동작했기 때문에 배포에도 문제가 없을 것이라 생각했다. 그러나 배포 사이트를 확인한 결과, API 요청이 이루어지지 않는 것을 확인했다.

이전에 1차적으로 관심사의 분리라는 주제로 리팩토링을 진행할 때 나름의 규칙을 정하고 관심사를 분리했다. 하지만 React-query와 zustand로 전환하는 과정에서 관심사 분리 기준에 대한 문제점을 인지했다. 무엇보다 ESLint를 적용하는 과정에서 모듈 간의 사

FSD(Folder Structure Design) 구조에 대해 학습하는 과정에서 현재 프로젝트와 겪고 있는 문제를 해결하기에 적합하다는 것을 알게 되었다. FSD는 기존의 모듈 아키텍처와 달리 명확한 기준이 있으며, 크게 Layer, Slice, Segments라는

상대 경로 -> 절대 경로 FSD 아키텍처를 적용하는 과정에서 디렉토리의 위치를 변경하는 과정에서 VS코드의 기본 설정이 상대 경로로 되어 있어 불편함을 겪었다. 상대경로는 경로 깊이가 얕을 때는 유용하지만, 깊어지면 위치를 파악하기 너무 힘들었다. 이 문제를 해결하

React-Test-Library 도입 FSD 아키텍처 도입을 위해 순차적인 리팩토링을 진행하는 과정에서, 매번 작업 후 수동으로 테스트하여 문제를 파악하는 과정이 번거롭고 불편하다는 생각이 들었다. 또한, 작은 변화가 예상치 못한 문제를 일으킬 수 있다는 불안감이

프로젝트 초기에 인증와 인가에 대해 문제로 많은 고민을 쏟아 특히나 토큰 관리에 대한 애착이 있었다. 신경쓴 만큼 이부분 만큼은 꼭 테스트코드를 작성하고 싶다는 생각이 들었다.axios.interceptor를 활용하고 있어 해당 부분에 대한 테스트 코드를 가장 먼저 고

board관련한 작업을 진행하는 도중 평문으로만 작성된 게시판이 밋밋하다는 생각이들었다. 평소에 마크다운문법을 즐겨 사용하여 게시글을 작성하는 편이어서, 게시판에 마크다운 문법을 적용하면 훨씬 깔끔하고 가독성 좋은 글을 작성할 수 있 것이라고 생각했다. 하지만, 마크다

사용자가 마우스로 텍스트를 드래그하면 선택된 내용을 첨삭하는 기능을 구현했다. 해당 기능은 원하는 동작으로 잘 작동했지만, 이번 리팩토링 과정에서 치명적인 버그를 발견하게되었다. 사용자가 마우스 이벤트가 없는 지역에서 시작해 이벤트가 있는 p태그로 드래그할 때 첨삭 액

빌드 속도 최적화 작업 이후, Husky와 Vercel의 Git-Action 기능 덕분에 별도의 빌드 테스트를 진행하지 않았다. Vercel의 빌드 과정에서 별다른 문제가 없었고, 커밋 시점에서 ESLint와 테스트 코드까지 점검하므로 빌드 속도에 대해 크게 신경 쓰지

미들웨어 너 왜 그래?? 미들웨어를 활용해 접근 권한을 통제했을 때, 개발자 모드에서는 모든 것이 정상적으로 작동하는 것처럼 보였다. 그러나 프로덕션 모드에서는 예기치 못한 버그가 발생했다. [정상 동작 동영상] [비정상 동작 동영상] 영상에서 확인할 수 있듯이,

최근 FSD 아키텍처로의 전환을 경험하면서 많은 도전과 배움을 얻게 되었다. 처음에는 단순히 디렉토리 구조를 정리하는 정도로 가볍게 생각했지만, 리팩토링을 시작하고 얼마 지나지 않아 FSD의 개념을 기존의 규칙이 정해진 디렉토리 구조에 적용하는 것이 쉽지 않다는 것을

테스트 코드를 검증하는 과정에서 갑자기 ReferenceError: TextEncoder is not defined라는 오류가 발생했습니다.이 오류의 원인은 TextEncoder라는 글로벌 객체가 정의되지 않았기 때문입니다. TextEncoder는 문자열을 UTF-8

React-Hook-Form 전환기 React-Hook-Form을 도입하기 이전 동적폼을 제어 컴포넌트 방식으로 관리하면서 겪었던 문제들에 대해서 이야기 해볼까 합니다. 제어, 비제어 ?? 유저가 선택한 템플릿을 기반으로 동적폼을 관리하기 위해서 제어, 비제어 컴포

이전글 이전글에서 제어 컴포넌트의 문제점을 해결하기위해 React-Hook-Form에 대해서 알아보았습니다. React Hook Form 이란 > React 개발자들을 위해 쉽게 폼을 구축할 수 있도록 지원하는 라이브러리이다. 폼 생성이 간단하고 검증이 쉬워 사용하

프로젝트를 최적화하기 위해 현재 컴포넌트내에서 불필요한 리렌더링의 문제가 있는지 점검이 필요했습니다. 하지만 다음과 같은 코드는 해당 컴포넌트가 리렌더링이 되는지는 알 수 있지만, 어떤 원인에서 리렌더링이 되는지는 파악하기 힘들다는 문제가 있었습니다.이런 문제를 해결하

"무슨 컴포넌트가 여기에?" 이코드는 또 어디에 분류하지... ? " 개발을 하다보면 누구나 한 번쯤 코드의 미로 속에서 길을 잃어본 경험이 있을 거에요. 특히 혼자 개발할 떄는 더 심해요. "어차피 나만 볼건데" 하는 마음으로 시작했다가 2주 후의 내가 내코드를