들어가며스터디에서 테스트 코드를 접했을 때 이런 생각을 했어요."코드가 잘 돌아가는 거 눈으로 확인했는데, 굳이 테스트 코드까지 써야 하나?"근데 프로젝트가 커지면서 기능 하나 수정했다가 다른 기능이 터지고, 어디서 터진 건지 추적하는 데 시간을 다 쓰는 경험을 하고 나서버그는 일찍 발견할수록 수정 비용이 작아요. 개발 중에 발견하면 커밋 하나로 끝나는 걸, 운영 중에 발견하면 hotfix 배포 리스크까지 감수해야 하니결국 테스트 코드는 규모가 큰 프로젝트에서 장기적으로 보았을 떄 유지보수를 위해 필요한 역량이겠구나.. 라고 생각했어요.이 글에서는 React 프로젝트에서 어떤 테스트를 어떻게 작성하면 좋은지 정리해보았습니다!테스트의 핵심 원칙테스트를 처음 배우면 내부 구현을 검증하고 싶어져요.상태가 이 ..

들어가며예전에 FSD(Feature-Sliced Design)를 선택한 이유와 기본 레이어 구조를 소개했었어요. 이번에는 한 발 더 나아가 아래의 주제를 추가적으로 다뤄보려 해요.Layered Architecture와 FSD의 관계아키텍처를 그리는 것보다 의존성을 어떻게 강제하는지가 더 중요하다는 것실제 프로젝트에서 FSD를 적용하며 부딪혔던 한계와 고민아키텍처가 필요한 이유새 파일을 만들 때 어디에 넣을지를 5분 이상 고민해본 적 있다면, 그건 아키텍처가 필요하다는 신호예요.기존에 쓰던 역할 중심 구조의 문제는 명확했어요. 하나의 기능과 관련된 코드가 여러 군데에 흩어져 있고, 그 코드들을 찾으려면 직접 생각의 흐름을 다시 꺼내 연결고리를 만들어가야 했어요. 처음엔 src/components, src/..

웹 개발에서 성능은 곧 사용자 경험, 그 자체입니다.웹 페이지가 1초 늦게 로드되면 전환율은 7%까지 떨어지고, 3초 이상 느리면 사용자의 53%가 이탈한다고 해요.프론트엔드 개발자는 점점 더 많은 기능을 담당하게 되었지만, 그만큼 성능에 대한 책임도 커졌어요.성능 이슈는 단순히 “빠르게 만들자”의 문제가 아니라, 렌더링 구조, 리소스 최적화, 이벤트 핸들링, 그리고 사용자 네트워크 환경까지 고려하는 일입니다.구현은 공식 문서나 라이브러리 가이드가 도와주지만, 성능 최적화는 어디에도 정답이 없고, 개발자가 직접 체감하고 해결해야만 하는 영역입니다.저는 React DevTools Profiler로 병목 구간을 찾고, useMemo / useCallback / memo로 불필요한 렌더링을 없애서 화면이 실제..

useQuery 한 줄로 데이터를 가져오는 건 쉽죠! 하지만 Query Key는 왜 배열이어야 하는지, Optimistic Update에서 cancelQueries를 빠뜨리면 어떤 일이 생기는지, Suspense와 ErrorBoundary가 어떻게 맞물리는지에 대한 생각을 작성했습니다!들어가며대부분의 웹 프레임워크는 데이터를 가져오거나 업데이트하는 정해진 규칙이 없어요이 때문에 개발자는 데이터를 처리하는 방법을 직접 고민해야하죠!React에서 useEffect를 사용하는 방법→ 데이터를 가져오거나 업데이트하는 코드를 컴포넌트 내부에 작성하여 상태와 side effect가 연결됨전역 상태 관리 라이브러리 사용→ 서버에서 가져온 데이터를 전역 상태 관리 도구에 저장하고 여러 컴포넌트에서 사용할 수 있도록 함..

들어가며공통으로 쓰이는 컴포넌트들, 즉 공용 컴포넌트라고 부르죠!잘 설계된 컴포넌트는 개발자에게 반복되는 UI 사용을 더 쉽고 빠르게 사용할 수 있도록 만들어주고, 디자이너와 개발자 사이의 커뮤니케이션 비용을 줄일 수 있어요. 사용자 입장에서는 여러 플랫폼에서 동일한 사용자 경험을 제공하는 기반이 돼요.효율을 위해 만드는 컴포넌트가 오히려 비용을 늘리는 상황이 생기지 않도록, 설계 원칙을 인지하고 지키려는 노력이 중요하다고 느껴요.그중에서도 가장 핵심적인 세 가지 주제를 정리해봤어요.단일 책임 원칙 (SRP) 컴포넌트 분리 원칙Presentational VS Container 패턴Compound Component 패턴단일 책임 원칙 SRP(Single Responsibilty Principle)이름에서도..

FSD 아키텍처란애플리케이션을 기능과 책임 중심으로 분리하여 구성하는 아키텍처 패턴이에요.기존의 역할 중심 구조와 달리 비즈니스 관점에서 의미 있는 단위를 기준으로 코드를 구성하는 것이 특징이에요.가장 중요한 규칙은 단방향 의존성이에요.자신보다 하위 레이어의 구성 요소만 참조하거나 import할 수 있어요.이 덕분에 코드 결합도를 낮추고, 특정 레이어의 변경이 다른 레이어로 확산되는 것을 방지할 수 있어요.FSD는 다음과 같은 레이어 구조를 기반으로 해요.shared : 프로젝트 전역에서 재사용 가능한 공통 유틸리티, 기본 컴포넌트, 스타일을 관리하는 레이어예요. 특정 기능이나 비즈니스 로직은 여기에 두지 않아요.└── shared/ ├── ui/ # 비즈니스 로직 없는 UI ├..

들어가며현재 우리 팀이 프로젝트 컨벤션 정하면서 스타일 라이브러리 선택에 고민이 많은데요 .. ! 😅Tailwind파 2명, vanilla-extract파 2명으로 의견이 나뉘는 중인데, 두 라이브러리를 객관적으로 비교하고, 우리 프로젝트에 맞는 선택을 근거 있게 내리기 위해 해당 글을 작성했습니다!비교 전, 기본 개념부터!React와 같은 SPA가 대두되면서 CSS in JS가 많이 사용됐다고 해요. React에서는 styled-component / emotion이 그 예시인데,CSS in JS의 장점CSS에서 JS 문법을 사용할 수 있어 생산성을 증가시킬 수 있다지역 스코프 스타일로 className이 겹치지 않음을 보장한다컴포넌트 파일에 관련 코드들과 동일 선상에서 같이 위치시킬 수 있다 (col..

프로젝트를 시작할 때마다 컨벤션을 정할 때 나오는 질문이 있죠 !"저희 프로젝트 전역 상태 관리 뭐 쓸까요?"저는 라이브러리를 써야하면, "zustand요!"라고 답하곤 하는데 사실 다른 건 잘 몰라서 그냥 선택하는 경우가 많았어요. 명확한 기준 없이 선택하고 있는 건 아닐까 싶어,이번 글에서는 전역 상태 관리 라이브러리를 선택하는 명확한 기준을 함께 고민해보려고 합니다.그래서3가지 라이브러리를 같은 예시로 직접 비교해보고실제 리렌더링 차이를 로그로 확인하고프로젝트 상황에 맞는 선택 기준 정리하려합니다!무엇보다 전역 상태가 정말 필요한지부터 먼저 고민해봐요!Q. 전역 상태 관리가 정말 필요한가요?전역 상태 관리 라이브러리를 도입하기 전에, 정말 필요한지부터 생각해봐야 합니다.전역으로 관리하면 좋은 것들:..

Tailwind CSS를 사용하다 보면 동적으로 클래스를 관리해야 할 때가 많습니다.이때 실무에 필수적으로 등장하는 clsx, tailwind-merge (twMerge), 그리고 이 둘을 합친 cn에 대해 정리해보고, 더 나아가 여기에 cva가 더해지면 어떤 강력한 시너지가 나는지에 대해 정리해보았습니다! tailwind를 설치하는 과정은 아래 블로그를 참고하세요!👉🏻 https://javascript.plainenglish.io/react-tailwind-reuseable-and-customizable-components-with-cva-clsx-and-tailwindmerge-combo-guide-c3756bdbbf16Part 1clsxclsx는 조건에 따라 클래스를 넣거나 뺄 때 사용하는 아주..

useEffect에서 side effect를 처리하는 법을 배워보자우선, Side Effect란?비동기 작업을 처리할 때 사용되는 것들렌더링과 관계없이 발생하는 동작 (ex: API 요청, 타이머, document.title 변경 등등)⚠️ 기존 문제점: 리액트의 “비동기” 처리여태까진 useState를 사용해 상태를 관리했지만, BUT 상태가 즉시 반영되지 않음마운팅되는 count 값 ≠ console.log()에 찍히는 count 값왜냐? → React의 상태 업데이트는 기본적으로 비동기적이기 때문즉, setState 호출 직후 console.log(count) 실행하면, count++하기 전, 즉 업데이트되기 전의 값이 찍히는 문제가 발생한다** 해결 방법: useEffect 사용**setState..

과제를 진행하면서 회원 관리 테이블을 만들었는데,검색 필터링, 체크박스 선택, 삭제, 추가 기능을 구현하던 중, 기능은 잘 작동했지만 필터링 후 삭제하면 필터가 풀리는 문제가 발생했습니다.이 문제를 해결하면서 바닐라 JS에서도 체계적인 상태 관리가 얼마나 중요한지 느꼈고, 그 과정을 공유하려고 합니다!🚨 문제 상황: 필터링 후 삭제하면 필터가 풀린다?재현 예시성별: 여자로 필터링 → 14명 표시그 중 3명을 체크해서 삭제문제 발생! → 필터가 풀리고 전체 목록(25명)이 다시 표시됨// 문제 코드const handleDeleteSelected = () => { const checkedCheckboxes = document.querySelectorAll(".member-checkbox:checked")..

useEffect에서 side effect를 처리하는 법을 배워보자우선, Side Effect란?비동기 작업을 처리할 때 사용되는 것들렌더링과 관계없이 발생하는 동작 (ex: API 요청, 타이머, document.title 변경 등등)⚠️ 기존 문제점: 리액트의 “비동기” 처리여태까진 useState를 사용해 상태를 관리했지만, BUT 상태가 즉시 반영되지 않음마운팅되는 count 값 ≠ console.log()에 찍히는 count 값왜냐? → React의 상태 업데이트는 기본적으로 비동기적이기 때문즉, setState 호출 직후 console.log(count) 실행하면, count++하기 전, 즉 업데이트되기 전의 값이 찍히는 문제가 발생한다** 해결 방법: useEffect 사용**setState..

혼자서 개발 공부를 할 땐 “기능만 돌아가면 됐지” 하고 생각한 적이 많았는데,이번 주엔 정말 작정하고 회원가입 폼을 직접 구현해보면서상태 관리, 입력, 에러 처리, 서버 연결 등 생각보다 훨씬 많은 구현 과정이 필요하단 걸 알게됐다⚠️ 겪었던 이슈💥 비밀번호 보기 버튼이 두 필드에 동시에 작동비밀번호 입력창과 비밀번호 확인창 모두에 "보기" 버튼을 붙였는데,하나만 클릭해도 두 필드가 동시에 보이거나 숨겨지는 이상한 현상이 발생했다✅ 해결 법: 상태 분리const [showPass, setShowPass] = useState(false);const [showPassCheck, setShowPassCheck] = useState(false);각 input에 각각의 상태를 연결해 문제 해결!이후 버튼도 개..

위 이미지는 어제 하루 종일 React 없이 TypeScript만으로 구현한 Todo List입니다최근 TypeScript의 안정성과 유지보수 편의성이 강조되며 중요도가 높아지고 있는 만큼, 어렵다는 인식보다는 JavaScript 개념을 제대로 다지는 것이 먼저라고 생각합니다TS에 익숙해지기 위한 방법으로, 공식 문서를 참고해 이론을 배우고 Todo List를 반복해서 만들어보며 실습했습니다TSX를 배우기 전, TypeScript의 기초 개념들을 정리해 블로그 글로 남겼습니다📘 Typescript란?🌟 TS와 JS의 차이를 중심으로Javascript의 상단 레이어, 즉 슈퍼셋(superset)JS의 기능을 제공하면서 그 위에 타입(string, number, object, symbol 등)을 정의하는..

모듈(module)= 분리된 코드 조각모듈은 서로 의존성을 띄고 있어서 다음과 같은 문제가 있음수많은 모듈의 순서를 어떻게 처리할지? (의존성 처리)모듈이 많아질 수록, HTTP 요청이 많아질텐데 이로 인한 오버 헤드?해결 방안: 모듈 번들러!##모듈 번들러분리된 코드 조각을 하나로 병합하는 개발 도구JS, CSS 파일 등 여러 리소스를 하나로 결합하여 단일 파일을 만듦브라우저는 하나의 단일 파일만 로드 -> 애플리케이션 동작번들(bundle)웹 개발 및 프엔 개발 용어여러 파일을 하나로 결합하는 작업하나의 파일로 결합하는 걸 "번들링"이라고 함번들링은 주로 JS, CSS 파일을 하나의 파일로 결합하는 걸 의미-> 웹 애플리케이션의 성능을 최적화하고 관리를 더 쉽게 만듦사용하는 이유번들링: 모듈들의 의..