본문 바로가기

Web Development

(78)
[RxJS] 3편. RxJS로 CRUD 구현하기 – 그리고 절차형처럼 느껴지는 부분 이번 글에서는 RxJS로 게시글 CRUD(생성, 조회, 삭제 등)를 어떻게 구현할 수 있는지 살펴보고, 그 과정에서 일부 코드가 절차형처럼 느껴지는 이유에 대해서도 함께 정리해본다.🧱 postStore.js – 전역 상태 + API 흐름 구성import { BehaviorSubject, Subject, from, of } from 'rxjs';import { switchMap, tap, catchError } from 'rxjs/operators';const postSubject = new BehaviorSubject([]);export const posts$ = postSubject.asObservable();const fetchTrigger$ = new Subject();// 초기 fetchfetc..
[RxJS] 2편. React에서 RxJS로 상태관리를 한다는 것은? React는 컴포넌트 기반 + 선언형 UI 프레임워크다. RxJS는 데이터 흐름을 선언적으로 다루는 스트림 라이브러리다. 그렇다면 React에서 RxJS로 상태 관리를 한다는 것은 어떤 의미일까?🌐 전역 상태를 스트림으로 선언RxJS에서는 전역 상태를 BehaviorSubject로 선언하고, 이를 Observable로 구독하게 만든다.const count$ = new BehaviorSubject(0);export const counter$ = count$.asObservable();export const increment = () => count$.next(count$.value + 1);📂 React Hook으로 구독function useCounter() { const [count, setCoun..
[RxJS] 1편. RxJS와 선언형 프로그래밍의 관계 1편. RxJS와 선언형 프로그래밍의 관계RxJS는 단순한 유틸리티 라이브러리를 넘어서, 선언형 프로그래밍의 철학을 코드에 옮긴 대표적인 예다. 이 글에서는 RxJS가 왜 선언형 프로그래밍과 관련이 깊은지 살펴보자.✨ 선언형 프로그래밍이란?- "무엇을 할 것인가"에 집중- 데이터 흐름을 명시적으로 선언하고, 내부의 처리 방식은 숨김- 대표 예시: HTML, SQL, React JSX, Array.map/filter⚡ RxJS는 선언형 프로그래밍 그 자체RxJS는 Observable 스트림을 통해 비동기 데이터를 선언적으로 다룬다. 직접 흐름을 제어하지 않고, 연산자를 조합해서 "무엇을 할 것인지" 선언한다.fromEvent(document, 'click') .pipe( map(event => ev..
React에서 useEffect를 꼭 써야 할까? — 오히려 안 써도 되는 경우가 더 많다 React에서 useEffect를 꼭 써야 할까? — 오히려 안 써도 되는 경우가 더 많다React를 쓰다 보면 useEffect를 거의 습관처럼 쓰게 되는 경우가 많다.상태를 바꾸거나, 데이터를 갱신하거나, 뭔가 “변화”가 있으면 useEffect부터 떠오른다.하지만 React 공식 문서에서는 이렇게 말한다:"You might not need an effect."(공식 문서: https://react.dev/learn/you-might-not-need-an-effect)📌 useEffect는 React의 '비상구'다React는 기본적으로 선언형 프로그래밍 철학을 따르고 있다.하지만 세상에는 선언형으로 다 표현할 수 없는 일들이 있다. 브라우저 타이틀 변경 외부 API 호출 이벤트 리스너 등록 ..
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..