2025-08-01 22:18

Status:

Tags: 리액트 넥스트

상태

  • 리액트 컴포넌트 내부에서 관리되는 데이터의 기억
  • UI의 동적 변화 가능하게 함
  • (일반) 실행 중인 프로그램의 메모리 및 변수 값

개념과 도입 배경

  • 이전 단순 html, css, js 로만 개발하던 시절엔 단순 입력이 생겨서 ui 변화를 주려면 전체 html 을 새로 가져와서 새로 만드는 식으로 동작

  • 또한 변수는 바뀌어도 페이지에서 바로 적용이 안됨, 새로 가져오거나 아니면 초기화 되버림

  • 뭐 제출하거나 간단한거 하나 바꾸자고 매번 새로 전체 페이지 렌더링 해야하는 문제

  • 렌더링 간 데이터 유지 불가

  • 변경 시 리렌더링 미발동

상태의 구조

1. 클래스 컴포넌트

  • 실제 컴포넌트의 동작은 클래스가 기본이었다.
  • 하지만 이런 객체 지향 방식이 보일러플레이트도 많고 워낙 복잡해서 현재는 거의 다 함수형으로
class MyComponent extends React.Component {
	constructor(props) {
		super(props);
		this.state = {count:0 , items:[]}
	}
}
	

2. 함수형 컴포넌트

  • 현재는 직접 . 찍어가며 객체를 리액트 객체를 건드는 게 아니라 useState을 만들어서 사용
  • 기존 클래스 컴포넌트 기능을 함수형 컴포넌트에서는 리액트 훅 으로 만들어서 사용
import { useState } from 'react';
function Counter() {
	const [count, setCount] = useState(0)
}

설계 원칙

클린코드 리액트에 나온 방식들이 많이 포함된다.

  • 관련된 데이터는 객체나 배열로 묶음
  • 명확히 enum 으로 구별
  • 불필요한 상태 만들지 않기

전역 상태 관리

  • 기존 상태는 모두 컴포넌트 안에서만 동작함
  • 하지만 테마나 인증 상태 처럼 서비스 전역에서 관리하고 접근, 사용 가능한 상태의 필요성 대두
  • zustand나 리덕스 같은 전역 상태 관리 라이브러리가 이를 해결
  • 리덕스나 MobX는 어렵고 복잡해서 별로였는데 zutand 가 쉽고 성능 좋아서 사실상 1황

References

zustand 본질적으로 왜 상태관리 라이브러리를 써야 하는가_ 리액트 상태(React State) 핸드북