대화형 Vite 앱이라고 브라우저에서 CSS를 생성해야 하는 것은 아닙니다. 버튼은 정적 스타일시트에 규칙이 이미 있는 두 class 사이를 전환할 수 있습니다. 중요한 구분은 인터페이스가 변하는지가 아니라 완전한 class 이름을 언제 사용할 수 있는지입니다.
소스에는 두 버튼 색상이 있고 빌드된 HTML에는 빈 마운트 지점이 있으며 브라우저 첫 렌더링에는 버튼 하나가 보이는 클라이언트 렌더링 앱을 생각해 보세요. 세 입력은 같은 앱을 나타내지만 Master CSS에 서로 다른 class 집합을 제공합니다.
이 페이지의 내용
#하나의 앱, 세 가지 입력
CSS 진입점이 로드된 기존 Vite 설정에서 시작하세요. 이 작은 바닐라 예제는 소스에 두 변형을 유지하고 JavaScript로 버튼을 만듭니다.
<div id="app"></div><script type="module" src="/src/main.js"></script>import './style.css'const tones = { blue: 'bg-blue', neutral: 'bg-neutral' }const button = document.createElement('button')let active = falsefunction update() { button.className = active ? tones.neutral : tones.blue button.textContent = active ? 'Selected' : 'Select'}button.addEventListener('click', () => { active = !active update()})update()document.getElementById('app').append(button)소스에는 bg-blue와 bg-neutral이 있습니다. HTML 파일에는 둘 다 없습니다. JavaScript가 아직 버튼을 만들지 않았기 때문입니다. 브라우저가 진입 모듈을 실행하면 연결된 버튼에 bg-blue가 생깁니다. 클릭하면 bg-neutral로 바뀝니다.
하나의 앱, 세 class 집합
같은 클라이언트 렌더링 앱에서 선택할 수 있는 생성 입력입니다. class 변경은 기존 정적 CSS를 재사용할 수 있으며 빈 HTML 마운트 지점은 초기 버튼 규칙을 제공하지 않습니다.
텍스트 설명
- 소스 → 정적 CSS. 버튼 소스에는 bg-blue와 bg-neutral이 모두 있습니다. 정적 모드는 상태 선택 전에 두 규칙을 생성합니다.
- 빌드 HTML → 사전 렌더링 CSS. 출력 HTML에는 빈 앱 마운트 지점만 있습니다. 버튼 class가 없으므로 pre-render 모드는 두 버튼 규칙 모두 생성하지 않습니다.
- 연결된 DOM → runtime CSS. 브라우저 첫 렌더링은 bg-blue 버튼을 연결합니다. runtime 모드가 해당 규칙을 생성하고 이후 bg-neutral로 전환하면 그 규칙도 생성합니다.
그림은 세 생성 전략의 입력을 비교합니다. 연속된 세 빌드 단계를 나타내거나 세 모드를 모두 실행하라고 권하는 것은 아닙니다.
#정적 CSS도 변하는 인터페이스를 지원할 수 있다
기본 masterCSS() 플러그인 설정에서는 스캐너가 src/main.js의 두 완전한 문자열을 찾습니다. 버튼에는 한 번에 하나의 class만 있어도 생성 스타일시트에는 두 규칙이 모두 포함됩니다. 클릭은 일치하는 기존 규칙을 바꿀 뿐 Master CSS에 CSS 생성을 요청하지 않습니다.
크기 선택, 상태 레이블, 탐색 선택처럼 유한한 상태에 적합합니다. 맵에 전체 class 문자열을 유지하세요. 대신 `bg-${tone}`을 구성하면 소스 근거가 사라집니다. 스캐너는 보간을 실행해 가능한 결과를 찾지 않기 때문입니다. 전체 class 작업 흐름과 명시적 소스 예외는 스캔과 가지치기에서 다룹니다.
CSS 사용 가능성과 앱 렌더링은 별개입니다. 이 예제에서 JavaScript를 끄면 정적 스타일시트는 존재하지만 버튼은 없습니다. 앱 코드가 버튼을 만들기 때문입니다. Master CSS 정적 모드는 클라이언트 렌더링 앱이 JavaScript 없이 동작한다고 보장하지 않습니다.
#빈 마운트 지점은 렌더링된 페이지가 아니다
Vite의 일반 프로덕션 빌드는 index.html을 기본 진입점으로 사용합니다. Master CSS pre-render 모드는 빌드가 출력한 HTML을 처리하며 앱 진입점을 실행해 마운트 지점을 버튼으로 바꾸지 않습니다.
masterCSS({ mode: 'pre-render' })에서 이 예제의 HTML에는 버튼 class가 없으므로 어느 색상에도 생성 규칙이 없습니다. 브라우저가 나중에 버튼을 만들 수는 있지만 pre-render 모드는 누락 규칙을 생성할 Master CSS 런타임을 제공하지 않습니다.
pre-render 모드는 빌드가 실제로 내용이 있는 HTML을 출력할 때 유용합니다. HTML에 이미 <button class="bg-blue">Select</button>이 있다면 Master CSS는 파란 class 규칙을 생성할 수 있습니다. neutral 변형이 클릭 후에만 나타나면 다른 CSS 소스가 여전히 필요합니다. 프레임워크가 HTML 생성을 담당하면 프레임워크 통합을 사용하세요.
#브라우저 생성은 연결된 class를 따른다
masterCSS({ mode: 'runtime' })에서는 런타임이 연결된 버튼을 관찰하고 파란 규칙을 생성합니다. 클릭으로 neutral class가 추가되면 해당 규칙도 생성합니다. 마지막 요소가 사용을 멈춘 후에도 규칙이 캐시에 남을 수 있습니다. 연결된 사용을 추적한다고 CSS가 즉시 제거되는 것은 아닙니다.
이 방식은 시각 편집기 입력처럼 브라우저에서 처음 존재하는 완전한 class 이름을 처리할 수 있습니다. 대신 생성 스타일은 런타임 시작에 의존합니다. 위의 유한 맵은 정적 모드만으로도 해당 의존성 없이 두 상태를 모두 지원합니다.
#점진적 렌더링이 유용한 경우
점진적 모드는 출력 HTML에서 생성한 CSS와 이후 class에 대한 브라우저 지원을 결합합니다. pre-render 모드와 같은 HTML 경계를 가집니다. 빈 마운트 지점은 초기 버튼 규칙을 제공하지 못합니다. 이 경우 앱 코드가 버튼을 만든 뒤에도 브라우저가 규칙을 생성해야 합니다.
HTML이 초기 인터페이스를 이미 담고 추가 class가 실제로 나중에 나타날 때 이 조합이 유용합니다. 초기 생성 CSS는 문서와 함께 도착하며 페이지 hydration manifest 덕분에 런타임은 엔진을 지연하면서 지원 class를 추적할 수 있습니다. manifest 밖의 class가 엔진을 시작합니다. 전체 모드 비교, hydration 동작, 실패 조건은 렌더링 모드 Guide에서 다룹니다.
이 메커니즘은 CSS를 사용할 수 있는 시점을 설명합니다. 페인트 시간 개선이나 전체 다운로드 감소를 입증하지는 않습니다. 이는 앱에 따라 달라지며 측정이 필요합니다.
#모드를 바꾸기 전에 입력 검증하기
예제를 프로덕션용으로 빌드한 뒤 출력 HTML과 실행 중인 DOM을 비교하세요. HTML에는 여전히 빈 마운트 지점이 있고 JavaScript 실행 후 DOM에는 버튼이 있어야 합니다. 정적 모드에서는 연결된 생성 스타일시트에 .bg-blue와 .bg-neutral이 모두 있는지 확인하고 버튼을 눌러 두 상태 모두 스타일이 적용되는지 확인하세요.
pre-render나 점진적 모드를 평가한다면 응답의 style#master-css에서 실제 앱 class와 규칙을 찾으세요. 브라우저 생성이 초기 누락을 숨길 수 있으므로 실행 중인 DOM만 보지 말고 응답 소스를 검사하세요. 개발 동작만으로 프로덕션 전달을 검증할 수는 없습니다.
소스에 보이는 class로 작업을 해결할 수 있다면 정적 모드를 유지하세요. 다른 입력은 소스가 제공하지 못하는 정보를 담고 있을 때 선택하고, 선택한 생명주기가 실제로 해당 정보를 제공하는지 검증하세요. 설치는 Vite Guide에, 렌더링 계약은 렌더링 모드에 있습니다.