본문 바로가기

Web Development

(58)
React를 쓰면서도 몰랐던 선언형 프로그래밍 이야기 React를 쓰면서도 몰랐던 선언형 프로그래밍 이야기React를 처음 접했을 때, 나는 그냥 시키는 대로 문법을 익히고, JSX를 따라 썼다.useState, map, onClick… 그렇게 UI를 만들고, 기능을 붙이고, 화면을 완성해 나갔다.그런데 어느 순간, 문득 이런 생각이 들었다.“나는 어떻게 UI를 구성하고 있었던 거지?”“이게 다 선언형 프로그래밍이라고?”React를 공부하면서 자연스럽게 사용했던 방식들이 사실은 선언형 프로그래밍이라는 걸, 꽤 시간이 지나서야 깨달았다.선언형 vs 절차형, 간단 정리스타일절차형 프로그래밍선언형 프로그래밍초점어떻게 처리할까무엇을 만들까특징명령 중심, 순차적의도 중심, 추상화예시DOM 직접 조작JSX로 UI 구조 선언절차형 프로그래밍은 “1번 하고 → 2번 하고..
상태관리 [5편]: Redux, Zustand, Tanstack Query — 언제, 무엇을 써야 할까? 🧠 상태 관리 도구, 왜 이렇게 많을까?프로젝트를 하다 보면 "이건 Redux로?" "Zustand가 더 쉽지 않나?" 같은 고민이 생깁니다.게다가 서버에서 데이터를 받아오면 Tanstack Query도 써야 한다고? 😵‍💫1. 도대체 이 도구들은 각각 뭘 하는 건가요?항목ReduxZustandTanstack Query주 역할전역 상태 관리간편한 전역 상태 공유서버 상태 관리 (fetch, cache 등)비동기 처리thunk, saga 등 외부 도구 필요fetch 직접 사용내장된 자동 처리캐싱직접 구현직접 구현기본 제공optimistic UI수동 구현수동 구현지원개발자 경험보일러플레이트 많음간단하고 직관적서버 상태 처리에 최적화주요 예시로그인, UI 상태모달, 다크모드게시물, 유저 정보 2. 예제로..
상태관리 [4편]: Tanstack-Query, 왜 프론트엔드에서 상태를 나눠 관리해야 할까? 🤔 왜 상태 관리가 이렇게 복잡할까?프론트엔드 개발을 하다 보면 “이 상태는 어디에 저장해야 하지?” 하는 고민이 생깁니다.로그인 정보, 모달 열림 여부, API 응답값까지…이 모든 걸 하나의 상태로 묶어도 될까요? 1. API에서 받아온 정보가 곧 클라이언트 상태 아닌가?처음엔 이렇게 생각할 수 있어요. “서버에서 데이터를 받아오면 그게 바로 상태지!”하지만 실제로는 두 가지 상태로 나눠서 관리하는 게 더 명확합니다.구분서버 상태 (Server State)클라이언트 상태 (Client State)정의서버에서 가져온 데이터브라우저 내부 UI 상태소유자서버가 원본 (Source of Truth)프론트엔드 앱예시게시물 목록, 유저 정보모달 열림 여부, 현재 페이지, 입력값동기화 필요예 (서버와 일치해야 함..
상태관리 [3편] - Zustand의 유연함이 대규모 프로젝트에서 어려운 이유 🌀 Zustand는 왜 Flux 아키텍처가 아닐까?Action이라는 개념이 필수 아님Dispatcher가 없음상태 변경 흐름을 엄격히 제어하지 않음set()으로 언제든지 상태 변경 가능⚔️ Zustand의 set() vs Redux의 dispatch()비유Redux (dispatch)Zustand (set)역할비서에게 메모 전달직접 수첩에 작성제어 흐름간접적 (Action → Reducer)직접 상태 변경디버깅액션 로그 추적 가능추적 어려움 (수동 로깅 필요)🚧 Zustand가 대형 프로젝트에서 어려운 이유1. 아키텍처와 구조 강제가 없다Redux는 구조 강제 → 협업에 유리Zustand는 자유로운 만큼 설계 일관성 부족2. 상태 변경 추적 어려움Redux: DevTool로 상태/액션 추적 가능Zus..
상태관리 [2편] - Redux vs Zustand 비교 – 왜 생겼고 언제 쓰는가? 📊 Redux vs Zustand 비교 요약항목ReduxZustand등장 시기2015년 (Flux 기반)2020년 (간단한 상태 관리 목적)철학Flux 아키텍처 기반의 단방향 흐름Flux와 무관, 간단한 API사용 목적예측 가능하고 구조화된 상태 관리가볍고 빠른 상태 공유코드 구조Action → Reducer → Store → Stateset()으로 직접 상태 변경보일러플레이트많음거의 없음미들웨어redux-thunk, redux-saga 등 별도 구성내장 미들웨어로 간단 설정 가능DevToolRedux 공식 DevTool 지원내장 DevTool 제공 (기능 제한적)상태 구독useSelector, connect 등Hook 기반리렌더링 제어최적화 필요선택적 구독으로 간단TypeScript 지원복잡한 타입 ..
상태관리 [1편] - Flux 패턴(아키텍처) 💡 Flux란? 왜 필요할까?단방향 데이터 흐름을 통한 예측 가능한 상태 관리 구조🧭 Flux란?Flux는 React와 함께 자주 언급되는 클라이언트 사이드 아키텍처 패턴입니다.단방향 데이터 흐름을 기반으로 상태를 예측 가능하게 관리할 수 있도록 설계되었습니다.Flux는 프레임워크가 아닌 개념적인 구조입니다.❓ Flux는 왜 등장했을까?기존 MVC 패턴의 한계모델과 뷰 사이의 양방향 데이터 흐름상태가 여러 곳에 흩어져 있음컴포넌트 간 의존성 증가유지보수와 디버깅 어려움📌 예시로 쉽게 이해해보기상황: 사용자에게 새로운 알림이 도착했습니다.헤더에 알림 아이콘이 있고, 목록 페이지에서도 알림을 확인할 수 있어야 합니다.❌ 기존 방식알림을 읽으면 헤더와 목록 상태를 각각 업데이트여러 컴포넌트에서 상태가 중..
[Next.js] Next.js 라우팅 방식의 장점과 다른 방식들과의 차이점 Routing이란?라우팅(Routing)은 URL과 페이지 컴포넌트를 연결하는 과정으로, 각 페이지의 경로를 정의하고 해당 경로에 어떤 컴포넌트를 제공할지 결정하는 것을 의미한다.다양한 라우팅 방식들명시적 라우팅개발자가 코드 내에서 직접 경로와 컴포넌트를 명시하는 방식이다.예를 들어, React에서는 다음과 같이 구현한다.@Controller('users') export class Users Controller { @Get() findAll():string { return 'This is ~~'; } }코드 기반 라우팅서버 측에서 코드로 경로를 정의하는 방식이다.Express.js에서는 다음과 같이 구현한다.app.get('/', (req, res) => { res.s..
[Next.js] 왜 우리는 Next.js를 사용하게 되었을까? Next.js를 빈번히 사용하는 프론트엔드 개발자의 입장에서,Next.js의 필요성에 대해서 정리해보았다.Next.js의 필요성을 알기 위해서는 Next.js가 어떤 배경에서 나타난 기술인지를 알아야 한다.웹 개발 방식의 변화 과정을 정리해보고, 거기서 어떤 문제를 해결하기 위해서 Next.js가 나타났는지 정리해보았다. 초기 웹사이트 개발서버 개발자들은 JSP와 같은 템플릿 엔진을 활용하여 서버에서 데이터를 주입한 HTML을 생성하고, 이를 사용자에게 전달하였다.AJAX의 등장웹의 상호작용성이 중요해지면서, 페이지 이동 시 깜빡임 등의 문제를 해결하기 위해 비동기 처리를 지원하는 AJAX가 도입되었다.CSR(Client-Side Rendering)의 부상JavaScript를 통해 클라이언트 측에서 동적..