React Udemy 강의 179번 정리

Side effect면 무조건 useEffect를 써야 한다고 생각했다면 틀렸다. useEffect는 남용하면 안 된다. 이번 강의의 핵심은 이거다.

1. Side Effect는 맞지만, useEffect가 필요 없는 경우

예시 상황

• 사용자가 place를 클릭함
• 선택한 장소를 state에 추가 → UI 업데이트
• 동시에 localStorage에 선택한 장소 목록 저장 (새로고침해도 유지되게 하기 위함)

function handleSelectPlace(id) {
  setSelectedPlaces((prev) => [...prev, id]);

  const storedIds =
    JSON.parse(localStorage.getItem('selectedPlaces')) || [];

  if (storedIds.indexOf(id) === -1) {
    localStorage.setItem(
      'selectedPlaces',
      JSON.stringify([id, ...storedIds])
    );
  }
}

이 코드는 side effect가 맞음. 하지만 useEffect는 필요 없음.

2. 왜 side effect인데도 useEffect를 안 써도 될까?

이 코드는 렌더링 때문에 실행되는 코드가 아니기 때문임. 이 코드는 컴포넌트 렌더링 중에 실행되지 않음. 오직 사용자 클릭 이벤트가 발생했을 때만 실행됨.

즉, 사용자 행동이 있어야 코드가 실행되기 때문에 state를 업데이트해도 무한 루프가 생기지 않음.

3. useEffect가 필요한 경우 vs 필요 없는 경우

useEffect가 꼭 필요한 경우

• 컴포넌트가 렌더링될 때 자동으로 실행되어야 하는 코드
• 렌더링 중 state 변경 → 무한 루프 위험 있는 코드

예를 들면, 위치 정보 가져오는 코드(navigator.geolocation), 서버 데이터 fetch, 렌더 이후 DOM에 접근해야 하는 코드 등등.

즉, 렌더링 → 자동 실행 이 구조일 때 useEffect 필요.

useEffect가 필요 없는 경우

• 사용자 이벤트로만 실행되는 코드
• 버튼 클릭, 리스트 클릭 등

예를 들면, localStorage 저장, 로그 남기기 등등..

즉, 사용자 액션 → 실행 이 구조일 때는 useEffect가 굳이 필요 없음.

4. 중요한 규칙 : Hooks는 어디서나 쓸 수 없다

function handleSelectPlace() {
  useEffect(() => {}); // 불가능
}

• Hooks는 반드시 컴포넌트 최상단에서만 사용 가능
• 조건문, 반복문, 이벤트 핸들러 안에서는 사용 불가!!

아무튼 이번 예제에서는 애초에 useEffect를 쓸 필요가 없음. 그래서 규칙 위반 문제도 발생하지 않음.

useEffect는 side effect를 관리하기 위한 도구이지 side effect를 무조건 감싸는 도구가 아니다.

useEffect는 렌더링 이후 자동으로 실행되어야 하는 로직에만 사용해야 하며, 사용자 이벤트로만 실행되는 side effect는 이벤트 핸들러 안에서 처리하는 것이 더 바람직하다.

React Udemy 강의 178번 정리

이번 강의의 핵심은 한 가지, "렌더링 중에 state를 바꾸면 왜 문제가 생기고, 그걸 useEffect로 어떻게 해결할까?"

1. 문제가 뭐였을까? (무한 루프)

사용자 위치를 가져와서 그 위치를 기준으로 장소 목록을 정렬. 그리고 그 결과를 state에 저장.

문제 코드의 핵심 구조

// 컴포넌트 함수 안
setAvailablePlaces(sortedPlaces);

이 코드가 컴포넌트 실행 중에 바로 실행됨.

왜 문제일까?

1. 컴포넌트 실행함
2. state 업데이트
3. state가 바뀌어서 컴포넌트 재실행
4. 다시 state 업데이트
5. 무한 반복..

즉, 렌더링 중에 side effect(state 변경)를 실행함.

2. Side Effect란?

렌더링과 직접적인 관련이 없는 작업을 말한다.

예를 들면, 데이터 fetch, 브라우저 API 사용(위치, localStorage 등), 타이머, interval 등등.

이런 작업은 렌더링 도중에 하면 안 됨.

3. useEffect는 언제 실행될까?

useEffect(() => {
  // side effect 코드
}, []);

useEffect 안의 코드는 컴포넌트가 렌더링된 이후에 실행됨.

즉, 렌더링 완료 후. 그래서 렌더링 중에 state를 바꾸는 문제가 사라짐.

4. 왜 의존성 배열([])이 중요할까?

useEffect(() => {
  // 위치 가져오고 state 업데이트
}, []);

의존성 배열의 의미

이번 예제에서는 사용자 위치를 앱 시작 시 한 번만 필요로 하기 때문에 [] 사용함. 결과적으로 무한 루프에서 벗어나 최초 1번만 실행함.

5. 왜 빈 배열이면 한 번만 실행될까?

React는 의존성 배열을 보고 판단함. 배열 안에 아무 값도 없으면 비교할 값이 없음. 즉, 바뀐 게 없음. 그렇다면, 다시 실행할 이유가 없음.

그래서 첫 렌더링 이후 딱 한 번만 실행하는 것.

6. fallback UI의 역할

<Places fallbackText="Sorting places by distance..." />

위치 정보 요청은 시간이 걸릴 수 있기 때문에 그동안 보여줄 UI가 필요함.

useEffect + fallback UI는 자연스러운 비동기 흐름.

useEffect는 렌더링과 무관한 작업(side effect)을 렌더링 이후 안전한 시점에 실행하도록 도와주는 훅이다.

Udemy React 강의 173번 정리

왜 useReducer가 필요할까?

현재 상황 (Context + useState)

• CartContextProvider 컴포넌트 안에서 장바구니 상태를 관리 중임
• 상태는 객체 / 배열 형태
• 상태 업데이트 로직이 점점 복잡해짐

문제점

• 항상 함수형 업데이트를 써야 함
• 로직이 길어질수록 가독성이 떨어짐
• 상태 변경 규칙이 컴포넌트 안에 흩어져 있음

이런 경우에 등장하는 게 useReducer

reducer란 무엇인가?

reduce의 기본 개념 (React 이전부터 있던 개념)

여러 값을 하나의 값으로 줄이는 함수임.

대표적인 예가 JavaScript의 reduce.

const total = items.reduce((sum, item) => {
  return sum + item.price * item.quantity;
}, 0);

이전값 + 규칙 → 새값 이 패턴을 상태 관리에 적용한 게 useReducer임.

useReducer의 핵심

상태 변경 로직을 한 곳(reducer)에 모으자!

useReducer는 두 가지를 반환함

const [state, dispatch] = useReducer(reducer, initialState);

• state : 현재 상태
• dispatch : action(행동)을 보내는 함수

useState의 setState와 다름! 직접 값을 넣는 게 아니라 action을 전달

reducer 함수의 구조

reducer는 반드시 이 형태를 가짐 :

function shoppingCartReducer(state, action) {
  return newState;
}

매개변수의 의미

React가 최신 state를 보장하기 때문에 이전 상태 기반 업데이트를 자동으로 처리함. 그래서 setState(prev => ...) 이런 패턴이 필요 없는 거임.

reducer는 왜 컴포넌트 밖에다가 두는 걸까?

function shoppingCartReducer(state, action) {
  return state;
}

이유

• props / state에 직접 접근할 필요 없음
• 컴포넌트 리렌더링 시 재생성될 필요 없음
• 순수 함수 유지

즉, 상태 변경 규칙만 정의하는 함수이기 때문임.

지금 단계에서 이 강의가 말하고자 하는 핵심은 useReducer는 복잡한 상태 변경 로직을 구조적으로 관리하기 위한 도구라는 것.

• Context + 복잡한 state → useReducer 궁합 좋음
• 무슨 일이 일어났는지(action) 중심 사고

Udemy React 강의 172번 정리

문제 상황 : App 컴포넌트가 너무 비대해짐

지금까지 App 컴포넌트에서 :

• 장바구니 state 관리 (useState)
• 아이템 추가 / 수량 변경 함수들
• Context에 전달할 value 객체 생성
• <CartContext.Provider value={...}> 설정

즉, Context + State + 로직이 전부 App에 몰려 있음. 이렇게 되면 App 컴포넌트가 점점 거대해지고, Context가 여러 개 생기면 App이 더 복잡해진다. 즉, 루트 컴포넌트는 깔끔해야 한다는 원칙에 어긋남.

해결 : Context 전용 Provider 컴포넌트 만들기

Context + State + 관련 로직을 App이 아니라 Context Provider 컴포넌트로 옮기는 것이다.

즉, Context를 사용만 하는 쪽(App)과 Context를 관리하는 쪽(Provider 컴포넌트)를 분리하는 것.

shopping-cart-context의 역할

이제 Context 파일은 단순히 createContext만 하는 것이 아니라 (1) 장바구니 state, (2) 아이템 추가 / 수정 로직, (3) Context에 전달할 value 구성, (4) Provider 컴포넌트 렌더링 이 모든 걸 담당한다.

// src/store/shopping-cart-context.jsx

export default function CartContextProvider({ children }) {
  const [shoppingCart, setShoppingCart] = useState({
    items: [],
  });

  function handleAddItemToCart(id) {
    setShoppingCart(prevShoppingCart => {
      const updatedItems = [...prevShoppingCart.items];

      const existingCartItemIndex = updatedItems.findIndex(
        cartItem => cartItem.id === id
      );
      const existingCartItem = updatedItems[existingCartItemIndex];

      if (existingCartItem) {
        const updatedItem = {
          ...existingCartItem,
          quantity: existingCartItem.quantity + 1,
        };
        updatedItems[existingCartItemIndex] = updatedItem;
      } else {
        const product = DUMMY_PRODUCTS.find(product => product.id === id);
        updatedItems.push({
          id: id,
          name: product.title,
          price: product.price,
          quantity: 1,
        });
      }

      return {
        items: updatedItems,
      };
    });
  }

  function handleUpdateCartItemQuantity(productId, amount) {
    setShoppingCart(prevShoppingCart => {
      const updatedItems = [...prevShoppingCart.items];
      const updatedItemIndex = updatedItems.findIndex(
        item => item.id === productId
      );

      const updatedItem = {
        ...updatedItems[updatedItemIndex],
      };

      updatedItem.quantity += amount;

      if (updatedItem.quantity <= 0) {
        updatedItems.splice(updatedItemIndex, 1);
      } else {
        updatedItems[updatedItemIndex] = updatedItem;
      }

      return {
        items: updatedItems,
      };
    });
  }

  const ctxValue = {
    items: shoppingCart.items,
    addItemToCart: handleAddItemToCart,
    updateItemQuantity: handleUpdateCartItemQuantity,
  };

  return (
    <CartContext.Provider value={ctxValue}>{children}</CartContext.Provider>
  );
}

이 컴포넌트는 데이터와 로직을 감싸서 제공하는 역할을 하는 거지, UI를 만들기 위한 게 아님. 그래서 children을 받아서 그대로 감싸줌.

Udemy React 강의 171번 정리

이번 강의의 목표는 Cart 관련 state + 로직을 전부 Context로 옮겨서 prop drilling을 완전히 제거하는 것이다.

1. 시작 상태 : prop drilling이 남아 있던 구조

이전까지 구조는 대략 이러했다.

App
 ├─ Header (cart items 개수 필요)
 ├─ Product (add to cart 함수 필요)
 └─ CartModal
     └─ Cart (items + update 함수 필요)

그래서 App에서 onAddToCart, cartItems, onUpdateCartItemQuantity 이런 props들이 계속 내려갔다.

문제는 중간 컴포넌트들은 이 props를 사용하지도 않는데 단지 전달만 하기 위해 존재하게 되는 것이었다. 전형적인 prop drilling.

2. App 컴포넌트 : Context Provider 정리

Context에서 제공하는 값들

  const ctxValue = {
    items: shoppingCart.items,
    addItemToCart: handleAddItemToCart,
    updateItemQuantity: handleUpdateCartItemQuantity,
  };

<CartContext.Provider value={ctxValue}>
  {children}
</CartContext.Provider>

이제 Context는 단순한 값 공유를 넘어서 cart items를 읽고, cart 업데이트 함수를 호출하는 것까지 모두 가능해짐.

4. Product 컴포넌트 : props 제거 → Context 사용

Before

<Product onAddToCart={handleAddItemToCart} />

After

const { addItemToCart } = useContext(CartContext);

<button onClick={() => addItemToCart(id)}>Add</button>

• Product는 이제 props를 하나도 받지 않음
• 필요한 건 Context에서 직접 가져옴

5. Header 컴포넌트 : cart 개수도 Context로

Header는 장바구니 개수만 필요함.

const { items } = useContext(CartContext);
const totalItems = items.length;

• 이제 App에서 Header로 cart 관련 props를 넘길 필요 없음

6. CartModal & Cart 컴포넌트 정리

• CartModal은 단순히 Cart를 감싸는 wrapper이기 때문에 Context 필요 없음
• Cart 컴포넌트는 items와 update 함수가 필요하기 때문에 Context 사용

const { items, updateItemQuantity } = useContext(CartContext);

7. 최종 결과 구조

App
 ├─ Header (Context 사용)
 ├─ Product (Context 사용)
 └─ CartModal
     └─ Cart (Context 사용)

Udemy React 강의 170번 정리

이번 강의에서는 Context 값을 사용하는 컴포넌트가 언제, 왜 다시 실행(리렌더링)되는지를 다뤘다.

핵심은 생각보다 단순하다. useContext로 Context 값을 사용하는 컴포넌트는 그 Context 값이 변경되면 자동으로 다시 실행된다.

React 컴포넌트는 언제 다시 실행될까?

컴포넌트 함수는 다음 세 가지 경우에 다시 실행된다.

1. 자기 자신의 state가 변경될 때
2. 부모 컴포넌트가 다시 실행될 때
3. 사용 중인 Context 값이 변경될 때 (이번 강의의 핵심)

Context를 "사용한다"는 게 무슨 뜻일까?

function Cart() {
  const cartCtx = useContext(CartContext);

  return <p>{cartCtx.items.length}</p>;
}

이 코드를 작성하는 순간, Cart 컴포넌트는 CartContext의 값(items)에 의존하게 된다.

즉, 이 컴포넌트는 CartContext 값이 바뀌면 다시 실행되어야 한다고 React는 이해한다.

Context 값이 바뀌면 실제로 무슨 일이 일어날까?

예를 들어 App 컴포넌트에서

setShoppingCart(prev => ({
  items: [...prev.items, newItem],
}));

이 코드가 실행되면 다음 순서로 일이 벌어진다.

1. shoppingCart state 변경
2. CartContext.Provider의 value 변경
3. Context 값이 변경됨
4. 이 Context를 사용하는 모든 컴포넌트가 다시 실행됨

이렇게 보면 state와 Context는 리렌더링 관점에서 비슷하게 느껴지는데.. 강의에서 강조하는 중요한 포인트는 이거다.

• state가 변경되면 컴포넌트가 다시 실행되듯이 Context 값이 변경되어도 컴포넌트는 다시 실행된다.

하지만 Context 값이 바뀌면 앱 전체가 다 리렌더링되는 건 아니다. 해당 Context를 실제로 사용하는 컴포넌트만 다시 실행된다. Context를 사용하지 않는 컴포넌트는 영향을 받지 않는다.

Udemy React 강의 168번 정리

이전까지 Context는 항상 빈 배열을 가진 정적인 값이었음.

<CartContext.Provider value={{ items: [] }}>

이제 목표는 : Context를 실제 state와 연결해서 값을 읽는 것뿐 아니라 값을 변경하는 것까지 Context로 처리하기.

1. Context를 State에 연결하는 가장 기본적인 방법

기존 상태

const [shoppingCart, setShoppingCart] = useState({
  items: [],
});

이 state의 구조는 이미 Context value와 동일함.

{
  items: []
}

그래서 가장 단순한 연결 방법은 이거 :

<CartContext.Provider value={shoppingCart}>

결과

• Cart 컴포넌트에서 cartCtx.items 읽기 가능
• state가 변경되면 Context도 자동으로 갱신됨

즉, Context = state의 읽기 창구 역할

하지만 지금 상태에서는 Context로 값 읽기는 가능하지만 Context로 값 수정은 불가능함. 여전히 addItemToCart 같은 함수는 props로 전달 중..

즉, Context를 쓰고 있지만 prop drilling이 완전히 사라진 건 아님.

2. 해결책 : Context에 함수도 함께 넣기

Context에는 데이터뿐 아니라 함수도 담을 수 있다.

Context value를 직접 구성하기

const ctxValue = {
  items: shoppingCart.items,
  addItemToCart: handleAddItemToCart,
};

그리고 Provider에 전달 :

<CartContext.Provider value={ctxValue}>

핵심 개념

• items → 상태 값
• addItemToCart → 상태를 변경하는 함수
• Context는 이제 읽기 및 쓰기 모두 가능해짐

Context 기본값에 함수를 넣는 이유는 딱 하나, 자동 완성 때문.

3. Context를 소비해서 state를 변경하기 (Product 컴포넌트)

이제 Product 컴포넌트에서는 더 이상 props가 필요 없다.

이전 방식

<Product onAddToCart={handleAddItemToCart />

Context 사용 방식

import { useContext } from 'react';
import { CartContext } from '../store/shopping-cart-context.jsx';

export default function Product({ id }) {
  const { addItemToCart } = useContext(CartContext);

  return (
    <button onClick={() => addItemToCart(id)}>Add to Cart </button>
    );
}

결과

• Product → Context → App state
• 중간 컴포넌트에 props 전달하지 않아도 됨
• prop drilling 제거

이제 구조는 이렇게 바뀜.

Product
  ↓ (Context)
CartContext
  ↓
App (state + 로직)

• 상태는 App에 있음
• 접근은 어디서든 Context로
• props는 UI 구성용으로만 사용

Context는 state 자체가 아님! Context는 state와 state 변경 함수에 접근하는 통로 역할임. Context에 함수를 넣으면 값을 읽는 것뿐 아니라 그 값을 변경하는 것도 가능함. 그 결과, prop drilling이 제거되고, 컴포넌트 결합도 감소되며, 구조가 훨씬 깔끔해짐.

Udemy React 강의 167번 정리

이번 강의에서는 Context를 제공한 뒤, 실제 컴포넌트에서 소비(consuming)하는 방법을 배웠다.

핵심은 props 대신 Context에서 값을 꺼내 쓰는 것이다.

1. Context를 왜 소비해야 할까?

현재 Cart 컴포넌트는 이런 역할을 한다.

• 장바구니 아이템 목록 출력
• 아이템이 없으면 fallback 메시지 출력
• 총 가격 계산

이전까지는 이 모든 데이터를 props로 전달받았다. 하지만 Context를 도입했으므로 이제는 props 없이 CartContext에서 직접 데이터를 가져와야 한다.

2. Context를 소비하는 방법 - useContext

기본 사용법

import { useContext } from 'react';
import { CartContext } from '../store/shopping-cart-context.jsx';

export default function Cart() {
  const cartCtx = useContext(CartContext);

  return (
    <>
      {cartCtx.items.length === 0 && <p>No items in cart!</p>}
      {cartCtx.items.map(item => (
        <li key={item.id}>{item.name}</li>
      ))}
    </>
  );
}

핵심

• useContext(Context객체) 형태로 사용
• 반환값은 Provider에서 제공한 value
• 더 이상 props.items 같은 건 필요 없음

3. Context를 소비하는 방법 - use 훅 (React 19 or React 19+)

import { use } from 'react';

const cartCtx = use(CartContext);

useContext와 use의 차이

일반적인 React 훅(useState, useContext 등)은 if 문이나 반복문 안에서 사용할 수 없다. 하지만 use 훅은 예외적으로 if 블록 안에서도 사용할 수 있어 조금 더 유연한 사용이 가능하다. 다만 use 훅은 React 19 혹은 그 이상에서만 지원되기 때문에 현재 기준으로는 useContext가 더 안전하고 범용적인 방식으로 사용된다.

4. Provider에 value를 꼭 설정해야 하는 이유

Context를 소비하려면 반드시 Provider에서 value를 제공해야 한다.

<CartContext.Provider value={{ items: [] }}>
  <App />
</CartContext.Provider>

만약 value를 안 주면?

• 에러 발생
• Context를 읽을 수 없음
• UI가 비어 보이거나 앱이 깨짐

Context 기본값(default value)은 왜 중요할까?

Context 생성 시 이런 코드를 썼다.

const CartContext = createContext({
  items: [],
});

이 기본값의 역할은

• 자동 완성(IntelliSense) 지원!
• cartCtx.items 같은 접근이 IDE에서 바로 보임
• 실제 앱 실행 시 같은 Provider의 value가 덮어씀

즉, 개발자 경험을 향상시키기 위한 설정임.

6. 구조 분해 할당으로 더 깔끔하게 쓰기

export default Cart() {
  const { items } = useContext(CartContext);

  return (
    <div>
      {items.length === 0 && <p>No items in cart!</p>}
    </div>
  )
}

지금은 Context에 하드코딩된 값을 넣고 있음. 다음 강의에서는 Context를 state와 연결해서 실제로 장바구니 아이템이 추가되고 삭제되도록 만들 예정.

Udemy React 강의 164번 정리

이번 강의에서는 prop drilling을 줄이는 한 가지 방법, 바로 컴포넌트 합성(Component Composition)에 대해 배웠다.

핵심은 상태를 어디에 두느냐보다 함수를 누구에게까지 전달해야 하느냐에 있다.

1. Prop Drilling이 생기는 이유

기존 구조

App
 └─ Shop
     └─ Product

• handleAddItemToCart 함수는 App에 있음
• 버튼 클릭은 Product에서 발생
• 그래서 App → Shop → Product로 함수가 계속 내려감

<App>
  <Shop onAddItemToCart={handleAddItemToCart}>
    <Product onAddToCart={handleAddItemToCart} />
  </Shop>
</App>

문제점

• Shop 컴포넌트는 이 함수를 사용하지 않음
• 그럼에도 불구하고 "전달"만 하기 위해 props를 받음
• 이런 구조가 반복되면 컴포넌트가 점점 지저분해짐

이게 prop drilling

2. 핵심 질문 하나로 정리하기

이 컴포넌트 안에서 이 함수가 실제로 실행되는가?

• YES → 함수 전달 필요
• NO → 함수 전달 불필요 (prop drilling 가능성)

3. 해결 방법 1 : Component Composition

접근 방식

• Shop이 제품을 직접 렌더링하지 않게 한다
• Shop은 단순히 "감싸는 역할"만 하도록 변경
• 실제 로직은 App에서 처리

4. 변경 전 그리고 변경 후 비교

변경 전 : Shop이 모든 걸 관리

function Shop({ onAddItemToCart }) {
  return (
    <ul>
      {products.map(product => (
        <Product
          key={product.id}
          onAddToCart={onAddItemToCart}
        />
      ))}
    </ul>
  );
}

• 제품 렌더링
• 함수 전달
• 중간 관리자 역할

변경 후 : Shop은 wrapper 역할만!

function Shop({ children }) {
  return <ul>{children}</ul>;
}

App에서 직접 Product 렌더링:

<Shop>
  {products.map(product => (
    <Product
      key={product.id}
      onAddToCart={handleAddItemToCart}
    />
  ))}
</Shop>

5. 무엇이 달라졌을까?

함수 전달 구조 변화

App → Product

• Product는 버튼 클릭 시 함수를 직접 실행
• Shop은 children만 감쌈 → 함수 몰라도 됨

즉, 함수가 필요한 컴포넌트에게만 전달됨.

하지만 이 방법에도 한계가 있다. 모든 로직을 App으로 끌어올리면 App 컴포넌트가 점점 비대해짐. 즉, 모든 prop drilling을 component composition으로 해결할 수는 없음.

그래서 다음 강의에서는 Context API / 전역 상태 관리를 배우게 될 예정.

Udemy React 강의 160번 정리

이번 강의의 핵심은 크게 두 가지.

1. Task를 어떻게 상태로 관리할 것인가
2. 왜 prop drilling이 문제가 되는가 (그리고 왜 다음에 다른 방법을 배우는지)

1. Task 입력: ref가 아니라 state를 쓰는 이유

상황

• NewTask 컴포넌트에 input + Add Task 버튼이 있음
• 버튼을 누르면 1) 입력된 task를 저장해야 하고, 2) input을 비워야 함

ref로 하면 안 될까?

가능은 함. 하지만 여기서는 React가 DOM을 제어하도록 두는 연습을 하기 위해 state를 사용함.

그래서 선택한 방식: controlled input (state)

import { useState } from 'react';

export default function NewTask({ onAdd }) {
  const [enteredTask, setEnteredTask] = useState('');

  function handleChange(event) {
    setEnteredTask(event.target.value);
  }

  function handleClick() {
    // 1. 먼저 입력된 값을 App 컴포넌트로 보내기
    // 2. 이 입력란을 빈 칸으로 리셋하기
    onAdd(enteredTask);
    setEnteredTask('');
  }

  return (
    <div className="flex items-center gap-4">
      <input
        type="text"
        className="w-64 px-2 py-1 rounded-sm bg-stone-200"
        onChange={handleChange}
        value={enteredTask}
      />
      <button
        className="text-stone-700 hover:text-stone-950"
        onClick={handleClick}
      >
        Add Task
      </button>
    </div>
  );
}

• onChange → 입력값을 state에 저장
• value={enteredTask} → state를 다시 input에 반영
• 버튼 클릭 시: (1) task 전달 (2) setEnteredTask('') → input 초기화

즉, 입력값을 직접 DOM에서 조작하지 않고, state로 관리.

2. Task는 어디에 저장해야 할까?

중요한 설계 포인트

• Task는 특정 Project에 속함
• Project와 Task를 모두 알고 있는 곳은? App 컴포넌트
• 그래서 1) Task 배열 상태는 App에 둔다 2) Task 추가 및 삭제 함수도 App에 둔다

3. Task 추가 흐름 (전체 데이터 흐름)

데이터 흐름 요약

NewTask
  ↓ (onAdd)
Tasks
  ↓
SelectedProject
  ↓
App (handleAddTask)

이게 바로 prop drilling임.

4. Prop Drilling이란?

정의

필요한 컴포넌트가 아닌데도 단지 전달만 하기 위해 props를 계속 내려보내는 것

실제로 여기서 발생한 일

• handleAddTask 함수는 App에 있음
• 하지만 버튼은 NewTask에 있음
• 중간 컴포넌트들: SelectedProject | Tasks
• 이 컴포넌트들은 함수를 쓰지도 않으면서 전달만 함

App
 └─ SelectedProject
     └─ Tasks
         └─ NewTask (여기서 실제로 사용)

중간 컴포넌트들이 점점 지저분해짐

이 강의에서는 Task 기능을 구현하는 것보다 state를 어디에 두어야 하는지와 prop drilling이 왜 불편해지는지를 직접 체감하는 게 핵심이었다.

다음 강의에서는 이 문제를 더 깔끔하게 해결하는 방법을 배운다.

Udemy React 강의 141번 정리

문제 상황

• setTimeout()은 한 번만 실행됨 → 경과 시간 추적 불가
• 목표 :
  • 시간이 지속적으로 얼마나 남았는지 추적
  • 시간이 끝나면 자동으로 모달 열기
  • 사용자가 중간에 STOP 눌러도 멈추기
  • 성공과 실패를 구분하여 표시

그래서 setTimeout 대신 setInterval을 사용하여 계속 시간 감소시키는 방식 필요

setInterval vs setTimeout 차이

왜 ref로 interval ID를 저장해야 할까?

핵심 : UI와 상관없는 값이지만 컴포넌트가 재실행되어도 유지되어야 하는 값 → ref에 저장!

setInterval + ref + state 조합이 필요한 이유

즉, UI에 반영되는 값(남은 시간)은 state, UI와 무관한 실행 상태(interval ID)는 ref.

성공 / 실패 처리 흐름

실패 → [조건] timeReamining <= 0 → "You lost!" 성공 → [조건] STOP 버튼 클릭 → "You win!"

둘다 동일하게 dialog.current.open() 호출. 즉, 내부 dialog가 어떻게 구현되었는지 TimerChallenge는 몰라도 됨. open이라는 컴포넌트 API만 호출하면 됨.

이 강의의 핵심 요약

setInterval로 남은 시간을 지속적으로 추적해야 하는 경우, ref와 state는 서로 다른 목적을 가진다. state는 UI를 업데이트하기 위한 값이며, ref는 UI와 무관하지만 유지되어야 하는 데이터를 저장하는 데 적합하다. React 컴포넌트에서 UI 반영 여부가 ref와 state를 구분하는 기준이다.

Udemy React 강의 140번 정리

<ResultModal ref={dialog} />

// 그리고 외부에서
dialog.current.showModal()

이전 방식은 이러하다. TimerChallenge 컴포넌트는 ResultModal 내부가 dialog라는 사실을 알고 있어야 하고, 만약 내부 DOM이 <dialog>에서 <div>로 바뀌면? showModal() 메서드는 존재하지 않고, 호출에 실패하여 결국 에러를 발생시킨다.

즉, 내부 구현을 외부가 알고 있어야 하는 구조, 즉, 매우 취약한 API가 된다.

큰 규모의 팀 프로젝트에서는 컴포넌트가 내부 DOM 구조를 바꿔도 외부 기능은 유지되는 게 중요하다.

해결 방법 — useImperativeHandle

ref.current에 내가 정의한 메서드를 저장해서 외부에서 호출할 수 있게 해준다.

예시 :

useImperativeHandle(ref, () => ({
  open() {
    dialog.current.showModal();
  }
}));

이제 외부에서는 다음만 호출하면 됨 :

dialog.current.open();

• 이제 외부는 dialog가 뭔지 몰라도 됨.
• 내부에서 DOM 구조가 바뀌어도 open()만 유지하면 되는 API 구조가 탄생!

코드 구조

ResultModal.jsx (구버전 방식 : forwardRef 사용)

import { forwardRef, useRef, useImperativeHandle } from "react";

const ResultModal = forwardRef(function ResultModal(props, ref) {
  const dialog = useRef();

  useImperativeHandle(ref, () => ({
    open() {
      dialog.current.showModal();
    }
  }));

  return <dialog ref={dialog}>...</dialog>;
});

export default ResultModal;

TimerChallenge.jsx

const dialog = useRef();

<ResultModal ref={dialog} />

dialog.current.open();

• 외부는 실제 HTML 요소의 메서드를 몰라도 되고, open()이라는 API만 알면 됨. 그리고 이 open이라는 이름은 내 마음대로 지을 수 있음. openSesame()여도 됨. 다만 팀 협업 시 이름은 의미가 명확해야 한다는 것.

useImperativeHandle 정리

Udemy React 강의 139번 정리

리액트에서 ref는 원래 DOM 요소에 연결할 때 사용한다.

<input ref={inputRef} />

하지만 커스텀 컴포넌트 내부의 DOM 요소에 ref를 연결하고 싶을 때는 상황이 조금 까다롭다.

강의 예제에서는 TimerChallenge → ResultModal 모달을 띄우기 위해 dialog 요소에 ref를 연결해야 한다.

1. 기본 개념 : ref는 DOM에만 직접 붙는다

다음 코드는 가능하다.

<dialog ref={dialog} />

하지만 다음은 기본적으로 동작하지 않는다.

<ResultModal ref={dialog} />   // 커스텀 컴포넌트라서 직접 ref 연결 불가

그래서 커스텀 컴포넌트가 ref를 전달받도록 처리해줘야 한다.

2. 최신 React (React 19 / 18.3~)에서는 그냥 ref props 받아서 하면 됨!

React 19에서는 아래 코드가 동작한다.

TimerChallenge.jsx

const dialog = useRef();

<ResultModal ref={dialog} />

ResultModal.jsx

export default function ResultModal({ ref }) {
  return <dialog ref={ref}> ... </dialog>;
}

그리고 TimerChallenge 안에서는 dialog.current.showModal(); 이렇게 하면 바로 dialog 요소를 조작할 수 있다.

최신 리액트는 ref를 일반 prop처럼 받을 수 있게 API가 바뀜 (그래서 forwardRef 없어도 됨)

하지만 구버전 React에서는 위 방식이 안 됨. 즉, ref를 커스텀 컴포넌트에 직접 잔달할 수 없었음. 그래서 구버전에서는 forwardRef를 사용해야 한다.

ResultModal.jsx

import { forwardRef } from 'react';

const ResultModal = forwardRef(function ResultModal(props, ref) {
  return (
    <dialog ref={ref}>{props.children}</dialog>
    );
});

export default ResultModal;

여기서 forwardRef가 컴포넌트를 특별한 형태로 감싸줌. 그래서 컴포넌트는 두 번째 인자로 ref를 전달받는다. (props, ref)

3. 왜 이러한 ref 전달이 필요한가?

모달을 열기 위해 showModal()을 호출해야 하기 때문임.

dialog.current.showModal();

• dialog는 HTML <dialog> 요소
• showModal()은 브라우저 내장 메서드
• → React와 무관
• 하지만 DOM 요소를 직접 조작해야 함

따라서 ref로 DOM에 접근해야 한다는 것.

Udemy React 강의 137번 정리

이 강의에서는 ref의 두 번째 핵심 용도를 다룬다. DOM 요소 말고도 UI에 직접 영향 없는 값을 저장할 때 ref를 쓸 수 있다는 점. 특히 타이머 예제를 통해 왜 변수나 useState로는 안 되고, 왜 ref가 정답인지 설명한다.

1. 문제 : 타이머를 정지해야 하는데,,,

setTimeout이 반환하는 타이머는 아래와 같이 사용할 수 있다.

const timer = setTimeout(() => {
  setTimerExpired(true)
}, targetTime * 1000)

clearTimeout(timer)

즉, 타이머를 멈추려면 타이머 ID(pointer)가 필요함.

그래서 처음엔 이렇게 생각할 수 있다.

let timer // 타이머 ID 저장

function handleStart() {
  timer = setTimeout(...)
}

function handleStop() {
  clearTimeout(timer)
}

하지만 이렇게 하면 제대로 작동하지 않는다.

2. 왜 단순 변수(let)로는 안 될까?

문제를 일으키는 핵심 이유 2가지 :

1) 컴포넌트 렌더링마다 변수 재생성

React는 state가 바뀌면 컴포넌트를 재실행(re-run)한다. 그리고 컴포넌트 안의 let timer는 렌더링이 다시 일어날 때마다 새로 선언되고, 이전 값은 사라진다. 즉, handleStart에 저장한 타이머 ID가 handleStop 실행 시점에는 사라져 버린 상태가 된다. 그래서 clearTimeout()이 제대로 호출되지 않음.

2) 여러 컴포넌트 인스턴스 사이에 공유됨

이 문제는 더 심각하다. 강의 예제처럼 5초 타이머 / 1초 타이머 두 개가 따로 렌더링된다면 어떻게 될까?

let timer

이 변수가 컴포넌트 함수 밖에 선언된다면, 두 컴포넌트 인스턴스가 같은 timer 변수를 공유하게 된다.

결과는,

1. 5초 타이머 시작 → timer = 5초 타이머 ID
2. 1초 타이머 시작 → timer = 1초 타이머 ID로 덮어씀
3. 5초 타이머 stop 누르면? → 이미 ID가 덮었음 → 5초 타이머는 안 멈춰짐
4. 결국 You lost! 뜸

즉, 컴포넌트 별로 독립된 타이머가 필요한데, 변수는 전부 공유된다.

3. 그렇다면 state로 저장하면 되지 않을까?

state를 사용하면, 또 다른 문제가 발생한다.

state로 타이머 ID를 저장하면,

const [timerId, setTimerId] = useState()

문제는,

• state 변경 → 리렌더 발생
• 리렌더 → setTimeout 사이드 이펙트 재실행 위험
• 리렌더는 타이머 관리 목적과 맞지 않음
• 타이머 ID 자체는 UI에 전혀 영향 없음

즉, UI를 바꿀 필요 없는 값 때문에 리렌더를 유발하면 불필요한 성능 소모가 발생한다.

4. 그래서 ref가 정답이다

ref는 다음과 같은 특징을 가지기 때문.

1) 리렌더 사이에서도 값이 유지됨 (state처럼 유지됨)

ref.current는 컴포넌트가 여러 번 렌더링되어도 값이 보존됨. 즉, handleStart에서 저장한 ID → handleStop에서도 그대로 살아 있음.

2) 컴포넌트마다 ref가 독립됨

각 TimerChallenge 컴포넌트마다 샌드박스처럼 독립된 ref 생성됨. 즉, 5초/1초 타이머가 서로 타이머 ID를 덮어쓰지 않음.

3) ref 변경은 리렌더를 유발하지 않음

state와 반대로 ref.current 변경은 리렌더를 유발하지 않고, UI에 영향을 주지 않는 값 관리에 최적함.

코드로 보자.

const timer = useRef(); 

function handleStart() {
  timer.current = setTimeout(() => {
    setTimerExpired(true);
  }, targetTime * 1000);
}

function handleStop() {
  clearTimeout(timer.current);
}

• 컴포넌트가 리렌더 되어도 timer.current 값 유지
• 여러 컴포넌트가 있어도 ID 충돌 없음
• UI 영향 받지 않음 (불필요한 리렌더 없음)

5. 최종 요약

변수(let)

• 렌더마다 초기화됨 → 값 보존 불가
• 여러 컴포넌트 인스턴스에서 공유됨 → 충돌 발생

state

• 값 유지됨
• 하지만 변경 시 리렌더 → UI에 필요 없는 렌더 발생

ref

• 값 유지됨
• 컴포넌트마다 독립됨
• 변경해도 리렌더 없음 (UI 영향 없는 값에 최적)

그래서 타이머 ID 같은 값은 ref로 관리하는 것이 정답이다.

Udemy React 강의 134번 정리

React에는 UI를 구성하는 두 개의 중요한 값이 있다.

• state : UI를 업데이트하기 위한 값
• ref : DOM 요소 또는 저장하고 싶은 값을 직접 참조하기 위한 값

둘은 "언제 사용하는가"와 "리렌더링이 발생하는가"에서 큰 차이를 가진다.

이번 글에서는 왜 ref만으로 UI를 업데이트할 수 없는지, state와 ref의 정확한 역할 차이를 살펴본다.

1. 왜 ref 값만 사용해서 UI를 업데이트하면 안 될까?

아래 코드가 왜 안 되는지부터 보자.

<p>{playerName.current.value}</p>

첫 번째 렌더에서 에러가 발생한다. → ref.current가 undefined

처음 컴포넌트가 렌더될 때는 아직 <input ref={playerName}>와 연결되기 전이다. → 따라서 playerName.current === undefined

그래서 첫 렌더 때 "Cannot read property 'value' of undefined" 같은 오류가 난다.

2. 해결처럼 보이는 코드도 결국 안 됨

강의에서 소개된 우회 코드 :

<p>{playerName.current ? playerName.current.value : "Unknown entity"}</p>

이렇게 하면 에러는 사라지지만, 버튼을 클릭해도 UI가 업데이트되지 않는다.

왜일까?

3. 핵심 차이 : ref는 변경되어도 리렌더링을 발생시키지 않음

이게 state와 ref의 가장 중요한 차이다.

React는 state가 변경될 때만 컴포넌트가 다시 실행된다. ref는 아무리 바뀌어도 컴포넌트를 다시 실행하지 않는다.

그래서 ref만으로는 UI가 업데이트 될 수 없다.

4. 왜 state가 필요한가?

state는 UI와 1:1로 연결되어 있기 때문에

• 값이 바뀐다 → 컴포넌트 재실행 → UI 업데이트

즉, UI에 즉시 반영되어야 하는 값은 반드시 state로 관리해야 한다.

반면 ref는 값이 바뀌어도 컴포넌트가 리렌더링 되지 않는다. 따라서 UI에 반영되지 않는다.

❗️ ref는 DOM에 접근하거나 렌더링과 무관한 값 저장용일 뿐, UI를 업데이트하려면 무조건 state를 사용해야 한다.

5. ref와 state는 서로 대체 관계가 아님!

React에서 두 값은 목적 자체가 다르다.

state를 써야 하는 경우

• 화면에 값이 보여야 할 때
• 값이 바뀌면 UI도 바뀌어야 할 때
• 입력값을 실시간으로 화면에 반영해야 할 때

ref를 써야 하는 경우

• DOM 요소에 직접 접근해야 할 때
• 입력값을 나중에 한 번에 가져올 때
• 값이 변경되어도 UI 업데이트가 필요 없는 경우
• 리렌더링을 피하고 싶을 때

이때 사용하는 것이 바로 Ref(Reference, 참조)이다.

1. Ref란 무엇인가?

Ref는 말 그대로 특정 요소를 가리키는 참조값.

• useState처럼 React가 관리하는 특별한 값
• 하지만 UI 업데이트를 위한 값이 아니라 DOM 요소(HTML 요소)에 직접 접근할 때 사용하는 값

Ref를 만들기 위한 Hook :

import { useRef } from 'react';

const playerNameRef = useRef();

2. Ref를 JSX 요소에 연결하기

모든 JSX 요소(내장 DOM 요소)는 ref라는 특별한 prop을 지원한다.

<input ref={playerNameRef} />

이렇게 연결하면 :

playerNameRef.current → 해당 input DOM 요소

여기서 핵심은 :

useRef()로 만든 ref 객체는 항상 { current: ... } 형태다. 진짜 값(여기서는 input 요소)은 current에 들어간다.

3. 왜 Ref가 필요할까? (State와의 차이)

보통 input 값 관리할 때는 state로 관리한다.

value={input}
onChange={(e) => setInput(e.target.value)}

하지만 이 방식은 타이핑할 때마다 re-render가 일어난다.

입력값이 단순히 저장만 필요할 때는 굳이 state로 관리할 필요가 없다. 이럴 때 Ref로 읽어오는 방식이 훨씬 단순하다.

4. Ref로 값 읽어오기 (onClick 시점에만 가져오기)

function clickHandler() {
  const entered = playerNameRef.current.value;
  setPlayerName(entered)l
}

이렇게 하면 (1)매 타이핑마다 렌더되지 않고, (2)필요할 때(버튼 클릭 시)에만 값 읽어오고, (3)컴포넌트 코드가 더 간결해진다.

5. 사용 예

기존 방식 : state로 모든 입력 변화 추적했음.

• onChange로 매 입력마다 state 갱신
• state로 value도 관리
• submitted state도 별도로 관리

💫 Ref 방식

const playerNameRef = useRef();
const [playerName, setPlayerName] = useState('');

function handleClick() {
  setPlayerName(playerNameRef.current.value); // DOM에서 직접 가져옴
}

return (
  <>
    <input ref={playerNameRef} />
    <button onClick={handleClick}>Set Name</button>
    <p>{playerName ?? 'Unknown entity'}</p>
  </>
);

• 타이핑할 때 UI가 리렌더링되지 않음
• 버튼 누른 순간에만 이름이 반영됨
• 코드가 더 간단함 (onChange, value props 필요 없음)

6. Ref는 언제 쓰는 게 맞을까?

Ref가 적합한 경우

• input 값이 즉시 UI 업데이트가 필요 없을 때
• 입력값을 한 번에 모아서 가져오고 싶을 때 (예: 폼 제출)
• 특정 DOM 메서드(focus(), scrollIntoView() 등)를 호출해야 할 때
• 애니메이션, 외부 라이브러리, Canvas 조작 등 DOM 직접 접근이 필요할 때

Ref가 적합하지 않은 경우

• 화면에 입력값을 실시간 반영해야 하는 경우 → 반드시 state로 관리!
• 리렌더링이 UI에 필요한 경우

즉, Ref는 React 안에서 DOM을 직접 다뤄야 할 때 가장 중요한 도구다.

1. 파일 안에 그대로 둘 것 vs. 분리할 것

Styled Components를 여러 개 만들다 보면 어떤 컴포넌트는 해당 파일에만 필요한 것이고, 어떤 컴포넌트는 여러 페이지 또는 컴포넌트에서 재사용될 가능성이 있는데, 이 두 가지를 구분하는 것이 핵심이다.

예시 : ControlContainer (div)

• AuthInput.jsx 안에서만 쓰임
• 다른 곳에서 재사용될 가능성 거의 없음 ➡️ 파일 안에 그대로 두는 것이 정답

예시 : Button, Input, Label

• 다른 페이지/폼에서도 반복해서 사용 가능
• 스타일을 통일하는 것이 UX적으로도 중요 ➡️ 별도 파일로 분리하는 것이 정답

이 글에서는 props로 스타일을 동적으로 변경하는 방법, $ prefix를 사용하는 이유, 가상 선택자(:hover) 적용, 중첩 규칙 적용, 미디어 쿼리를 Styled Components 안에서 작성하는 방법을 정리한다.

1. Styled Components로 조건부 스타일링하기

Styled Components의 진짜 강점은 props에 따라 동적으로 CSS를 바꿀 수 있다는 것이다.

예 : label이 invalid일 때만 빨간색으로 스타일 바꾸기

const Label = styled.label`
  color: ${(props) => (props.$invalid ? '#ff6b6b' : '#333')};
`;

jsx에서는 아래와 같이 작성한다.

<Label $invalid={!emailIsValid}>Email</Label>

어떻게 동작하는 걸까? props.$invalid는 true/false 값을 받고, Styled Components는 CSS 템플릿 리터럴 안에서 자바스크립트 함수를 실행해 그 반환값을 CSS에 삽입한다.

즉, 조건부 className 없이 깨끗하게 스타일을 토글할 수 있다.

2. 왜 $invalid처럼 $ prefix를 붙일까?

Styled Components는 모든 props를 실제 DOM 요소로 전달한다.

예를 들어 :

<label invalid="false">

이런 식으로 렌더링되면 브라우저에서 "invalid"는 HTML built-in attribute라고 판단해서 콘솔 경고가 뜬다.

그래서 Styled Components는 스타일링용 props에 $invalid, $error, $active처럼 $ prefix를 붙이는 패턴을 권장한다.

참고로 $로 시작하는 props는 DOM으로 전달되지 않음! (Styled Components 내부에서만 사용됨)

3. Input에도 조건부 스타일 적용하기

입력값이 invalid일 때만 배경, 테두리, 글자색을 바꾸고 싶다면?

const Input = styled.input`
  background-color: ${(p) => (p.$invalid ? '#fddddd' : '#f3f3f3')};
  border-color: ${(p) => (p.$invalid ? '#ff6b6b' : 'transparent')};
  color: ${(p) => (p.$invalid ? '#ff6b6b' : '#333')};
`;

jsx에서는 아래와 같이 작성한다.

<Input $invalid={!emailIsValid} />

이 방식은 클래스를 토글하는 방식보다 더 선언적이고, JSX가 더 깔끔해지고, CSS가 컴포넌트 근처에 있어서 관리하기 쉽다.

4. 중첩 규칙 (Nested Selectors)

Styled Components 안에서는 CSS에서 사용하던 중첩 구조를 그대로 사용할 수 있다.

예 : 부모 header 안의 img, h1 등을 한 번에 스타일링하기

const Header = styled.header`
  display: flex;
  flex-direction: column;

  & img {
    width: 120px;
  }

  & h1 {
    font-size: 2rem;
  }
`;

&의 의미

• & = 현재 styled component 자신
• & img = Header 내부의 img 요소
• & h1 = Header 내부의 h1 요소

이 방식 덕분에 각각을 따로 Styled Component로 만들지 않아도 된다.

5. Pseudo Selector (가상 선택자) 사용하기 [:hover]

Hover 스타일도 매우 간단하게 적용할 수 있다.

const Button = styled.button`
  background-color: #222;
  padding: 1rem;

  &:hover {
    background-color: #333;
  }
`;

6. Media Query도 똑같이 사용 가능

CSS에서 하던 방식 그대로 작성하면 된다.

const Header = styled.header`
  margin-bottom: 2rem;

  @media (min-width: 768px) {
    margin-bottom: 4rem;
  }
`;

CSS와 99% 동일하다는 점이 Styled Components의 큰 장점 중 하나.

이 글에서는 props로 스타일을 동적으로 변경하는 방법, $ prefix를 사용하는 이유, 가상 선택자(:hover) 적용, 중첩 규칙 적용, 미디어 쿼리를 Styled Components 안에서 작성하는 방법을 정리한다.

1. Styled Components로 조건부 스타일링하기

Styled Components의 진짜 강점은 props에 따라 동적으로 CSS를 바꿀 수 있다는 것이다.

예 : label이 invalid일 때만 빨간색으로 스타일 바꾸기

const Label = styled.label`
  color: ${(props) => (props.$invalid ? '#ff6b6b' : '#333')};
`;

jsx에서는 아래와 같이 작성한다.

<Label $invalid={!emailIsValid}>Email</Label>

어떻게 동작하는 걸까? props.$invalid는 true/false 값을 받고, Styled Components는 CSS 템플릿 리터럴 안에서 자바스크립트 함수를 실행해 그 반환값을 CSS에 삽입한다.

즉, 조건부 className 없이 깨끗하게 스타일을 토글할 수 있다.

2. 왜 $invalid처럼 $ prefix를 붙일까?

Styled Components는 모든 props를 실제 DOM 요소로 전달한다.

예를 들어 :

<label invalid="false">

이런 식으로 렌더링되면 브라우저에서 "invalid"는 HTML built-in attribute라고 판단해서 콘솔 경고가 뜬다.

그래서 Styled Components는 스타일링용 props에 $invalid, $error, $active처럼 $ prefix를 붙이는 패턴을 권장한다.

참고로 $로 시작하는 props는 DOM으로 전달되지 않음! (Styled Components 내부에서만 사용됨)

3. Input에도 조건부 스타일 적용하기

입력값이 invalid일 때만 배경, 테두리, 글자색을 바꾸고 싶다면?

const Input = styled.input`
  background-color: ${(p) => (p.$invalid ? '#fddddd' : '#f3f3f3')};
  border-color: ${(p) => (p.$invalid ? '#ff6b6b' : 'transparent')};
  color: ${(p) => (p.$invalid ? '#ff6b6b' : '#333')};
`;

jsx에서는 아래와 같이 작성한다.

<Input $invalid={!emailIsValid} />

이 방식은 클래스를 토글하는 방식보다 더 선언적이고, JSX가 더 깔끔해지고, CSS가 컴포넌트 근처에 있어서 관리하기 쉽다.

4. 중첩 규칙 (Nested Selectors)

Styled Components 안에서는 CSS에서 사용하던 중첩 구조를 그대로 사용할 수 있다.

예 : 부모 header 안의 img, h1 등을 한 번에 스타일링하기

const Header = styled.header`
  display: flex;
  flex-direction: column;

  & img {
    width: 120px;
  }

  & h1 {
    font-size: 2rem;
  }
`;

&의 의미

• & = 현재 styled component 자신
• & img = Header 내부의 img 요소
• & h1 = Header 내부의 h1 요소

이 방식 덕분에 각각을 따로 Styled Component로 만들지 않아도 된다.

5. Pseudo Selector (가상 선택자) 사용하기 [:hover]

Hover 스타일도 매우 간단하게 적용할 수 있다.

const Button = styled.button`
  background-color: #222;
  padding: 1rem;

  &:hover {
    background-color: #333;
  }
`;

6. Media Query도 똑같이 사용 가능

CSS에서 하던 방식 그대로 작성하면 된다.

const Header = styled.header`
  margin-bottom: 2rem;

  @media (min-width: 768px) {
    margin-bottom: 4rem;
  }
`;

CSS와 99% 동일하다는 점이 Styled Components의 큰 장점 중 하나.

Styled Components는 CSS 파일도, inline 스타일도 아닌 스타일이 적용된 React 컴포넌트를 직접 생성하는 방식이다. 즉, 스타일과 컴포넌트를 하나의 단위로 묶어 UI를 구성하게 해준다.

1. Styled Components란?

Styled Components는 서드 파티 라이브러리로 JS 파일 안에서 스타일을 작성하고 그 스타일이 적용된 커스텀 컴포넌트를 만들어 쓸 수 있는 방식이다.

설치

npm install styled-components

설치 후 프로젝트를 새로 실행해야 할 수도 있다.

2. 기본 사용법 : styled.div 생성하기

styled-components를 사용하려면 먼저 styled를 import한다.

import styled from 'styled-components';

그리고 다음처럼 styled.div 형태로 새로운 컴포넌트를 만들 수 있다.

const ControlContainer = styled.div`
  margin-bottom: 1rem;
  display: flex;
  flex-direction: column;
`;

여기서 중요한 점,

• backtick(`) 안에는 순수한 CSS 코드를 그대로 작성한다.
• PascalCase로 작성.
• 멀티 라인 작성 가능.

결과적으로 스타일이 적용된 div 컴포넌트가 만들어진다.

이제 기존 div 대신 아래와 같이 사용한다.

<ControlContainer>
  ...
</ControlContainer>

3. Styled Components가 동작하는 방식

Styled Components는 내부적으로,

1. 우리가 작성한 CSS를 빌드 시 고유한 클래스명으로 변환한다.
2. 이 고유한 클래스를 <head>에 삽입한다.
3. 해당 클래스를 우리가 만든 컴포넌트에 자동으로 붙인다

즉, CSS Modules처럼 스코프가 보장되며, 우리는 className을 일일이 관리할 필요 없이 스타일이 적용된 컴포넌트만 사용하면 된다.

4. Styled Components로 기본 요소(label, input)도 재정의하기

Styled Components는 div 뿐만 아니라 모든 HTML 태그를 대상으로 만들 수 있다.

예 : label 스타일링

const Label = styled.label`
  font-weight: bold;
  margin: 0.5rem 0;
  color: #333;
`;

컴포넌트에서 사용할 때는 아래와 같이 사용한다.

<Label>Email</Label>

예 : input 스타일링

const Input = styled.input`
  padding: 0.5rem;
  border-radius: 6px;
  border: 1px solid #ccc;
`;

컴포넌트에서 사용할 때는 아래와 같이 사용한다.

<Input type="email" onChange={...} />

5. ⭐️ Styled Components만의 핵심 특징 : props 자동 전달

Styled Components는 내부에서 기본 HTML 요소(label, input 등)을 생성한다. 그리고 그 요소에게 우리가 전달한 props를 그대로 forwarding한다.

예 :

<Input
  type="password"
  onChange={passwordChangeHandler}
  className={!passwordIsValid ? 'invalid' : ''}
/>

이 모든 props는 내부의 실제 <input>에게 그대로 전달된다.

즉, 이벤트 리스너(onChange, onBlur), HTML 속성(type, value), className, style, aria-* 전부 문제 없이 동작한다.

이 덕분에 styled input이냐, 기본 input이냐의 차이만 있을 뿐 나머지 로직은 그대로 유지된다.

6. Styled Components의 장단점

장점

1) 컴포넌트 단위 스타일 관리

• 스타일과 구조가 하나의 파일, 한 덩어리로 묶여 유지보수가 쉬움.

2) 스코프 자동 보장

• 클래스 이름은 자동으로 유니크하게 변환되므로 충돌 없음.

3) 순수 CSS 그대로 사용

• CSS 문법 변형 없이 그대로 사용 가능.

4) 조건부 스타일링 / props 기반 스타일링 강력 (이 부분은 다음 강의에서 더 깊이 다룸!)

5) className 안 써도 됨

• "이 컴포넌트는 이 스타일이다"라는 개념이 명확해짐.

단점

1) 서트 파티 라이브러리 설치 필요

• 번들 크기가 증가할 수 있음.

2) JS 안에 스타일이 들어오므로 파일이 길어질 수 있음

• 취향에 따라 가독성이 떨어진다고 느끼는 사람도 있음.

3) 모든 컴포넌트가 styled 컴포넌트가 되면 요소 구조 파악이 어려울 수 있음

• 개발자 도구에서 <label class="sc-hvigdm eEJnQf"></label> 같은 형태로 보임.