Failed to load}>
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/exhaustive-deps.md b/src/content/reference/eslint-plugin-react-hooks/lints/exhaustive-deps.md
index 9e855ba3e..4f2f00c87 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/exhaustive-deps.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/exhaustive-deps.md
@@ -8,19 +8,19 @@ React Hook의 의존성 배열에 필요한 모든 의존성이 포함되어 있
-## 규칙 자세히보기 {/*rule-details*/}
+## 규칙 세부 사항 {/*rule-details*/}
-`useEffect`, `useMemo`, `useCallback`과 같은 React Hook은 의존성 배열을 받습니다. 이 Hook들 안에서 참조한 값이 의존성 배열에 포함되지 않으면 그 값이 바뀌어도 React가 effect를 다시 실행하거나 값을 다시 계산하지 않습니다. 그 결과 Hook이 예전 값을 계속 붙잡고 사용하는 "stale closure(오래된 클로저)" 문제가 생겨 최신 값이 아닌 상태로 동작하게 됩니다.
+`useEffect`, `useMemo`, `useCallback`과 같은 React Hook은 의존성 배열을 받습니다. 이 Hook들 안에서 참조한 값이 의존성 배열에 포함되지 않으면, 그 값이 바뀌어도 React가 Effect를 다시 실행하거나 값을 다시 계산하지 않습니다. 그 결과 Hook이 예전 값을 계속 붙잡고 사용하는 오래된 클로저Stale Closure 문제가 생겨 최신 값이 아닌 상태로 동작하게 됩니다.
-## 흔한 위반 사항 {/*common-violations*/}
+## 일반적인 위반 사례 {/*common-violations*/}
-이 오류는 effect 실행 시점을 조절하려고 의존성을 의도적으로 누락할 때 자주 발생합니다. Effect는 컴포넌트를 외부 시스템과 동기화하기 위한 용도여야 합니다. 의존성 배열은 effect가 어떤 값을 사용하고 있는지 React에게 알려주며, React는 이를 바탕으로 언제 다시 동기화해야 하는지 판단합니다.
+이 오류는 Effect 실행 시점을 조절하기 위해 의존성을 의도적으로 누락할 때 자주 발생합니다. Effect는 컴포넌트를 외부 시스템과 동기화하기 위한 용도여야 합니다. 의존성 배열은 Effect가 어떤 값을 사용하고 있는지 React에게 알려주며, React는 이를 바탕으로 언제 다시 동기화해야 하는지 판단합니다.
-린터 경고를 계속 피하려고 하거나 맞추기 어렵다고 느낀다면, 코드 구조를 다시 구성해야 할 가능성이 큽니다. 방법은 [Effect의 의존성 제거하기](/learn/removing-effect-dependencies) 문서를 참고하세요.
+린터와 싸우고 있는 자신을 발견한다면, 아마도 코드 구조를 다시 구성해야 할 가능성이 큽니다. 자세한 방법은 [Effect의 의존성 제거하기](/learn/removing-effect-dependencies) 문서를 참고하세요.
-### 유효하지 않음 {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-이 규칙에 대한 잘못된 코드 예시
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
// ❌ Missing dependency
@@ -39,9 +39,9 @@ useMemo(() => {
}, [items]); // Missing 'sortOrder'
```
-### 유효 {/*valid*/}
+### 올바른 예시 {/*valid*/}
-이 규칙에 대한 올바른 예시
+이 규칙에 대한 올바른 예시입니다.
```js
// ✅ All dependencies included
@@ -59,7 +59,7 @@ useEffect(() => {
### 함수를 의존성으로 추가하면 무한 루프가 발생할 수 있습니다 {/*function-dependency-loops*/}
-effect를 사용하고 있지만, 렌더링이 일어날 때마다 새로운 함수를 매번 생성하고 있습니다.
+Effect를 사용하고 있지만, 렌더링이 일어날 때마다 새로운 함수를 매번 생성하고 있습니다.
```js
// ❌ Causes infinite loop
@@ -72,7 +72,7 @@ useEffect(() => {
}, [logItems]); // Infinite loop!
```
-대부분의 경우 effect는 필요하지 않습니다. 대신 그 동작이 실제로 발생하는 지점에서 함수를 호출하세요.
+대부분의 경우 Effect는 필요하지 않습니다. 대신 그 동작이 실제로 발생하는 지점에서 함수를 호출하세요.
```js
// ✅ Call it from the event handler
@@ -88,7 +88,7 @@ items.forEach(item => {
});
```
-정말로 effect가 필요한 경우(예: 외부 무언가를 구독해야 하는 경우)에는, 의존성이 안정적이도록 만드세요.
+정말로 Effect가 필요한 경우(예: 외부 무언가를 구독해야 하는 상황)에는, 의존성이 안정적이도록 만드세요.
```js
// ✅ useCallback keeps the function reference stable
@@ -106,9 +106,9 @@ useEffect(() => {
}, [items]);
```
-### effect를 한 번만 실행하기 {/*effect-on-mount*/}
+### Effect를 한 번만 실행하기 {/*effect-on-mount*/}
-마운트 시점에 effect를 한 번만 실행하고 싶지만, 린터가 누락된 의존성에 대해 경고합니다.
+마운트 시점에 Effect를 한 번만 실행하고 싶지만, 린터가 누락된 의존성에 대해 경고합니다.
```js
// ❌ Missing dependency
@@ -117,7 +117,7 @@ useEffect(() => {
}, []); // Missing 'userId'
```
-의존성을 포함하는 것이 권장되며, 정말로 한 번만 실행해야 한다면 Ref를 사용하세요.
+의존성을 포함하는 것을 권장하며, 정말로 한 번만 실행해야 한다면 Ref를 사용하세요.
```js
// ✅ Include dependency
@@ -140,7 +140,7 @@ useEffect(() => {
## 옵션 {/*options*/}
-공유 ESLint 설정을 사용해 커스텀 Effect Hook을 설정할 수 있습니다(`eslint-plugin-react-hooks` 6.1.1 이상에서 지원).
+공유 ESLint 설정을 사용해 커스텀 Effect Hook을 설정할 수 있습니다. (`eslint-plugin-react-hooks` 6.1.1 이상에서 지원.)
```js
{
@@ -152,9 +152,9 @@ useEffect(() => {
}
```
-- `additionalEffectHooks`: 철저한 의존성 검사를 적용해야 하는 커스텀 Hook을 정규식 패턴으로 지정합니다. 이 설정은 모든 `react-hooks` 규칙에서 공통으로 사용됩니다.
+- `additionalEffectHooks`: Exhaustive Deps 검사를 적용해야 하는 커스텀 Hook을 정규식 패턴으로 지정합니다. 이 설정은 모든 `react-hooks` 규칙에서 공통으로 사용됩니다.
-하위 호환성을 위해 이 규칙은 규칙 단위 옵션도 함께 지원합니다.
+하위 호환성을 위해 이 규칙은 규칙 단위Rule Level 옵션도 함께 지원합니다.
```js
{
@@ -166,4 +166,4 @@ useEffect(() => {
}
```
-- `additionalHooks`: 빠짐없는 의존성 검사(exhaustive deps)를 적용해야 하는 Hook을 정규식으로 지정합니다. **참고:** 이 규칙별 옵션을 지정하면 공유 `settings` 설정보다 우선 적용됩니다.
+- `additionalHooks`: Exhaustive Deps 검사를 적용해야 하는 Hook을 정규식으로 지정합니다. **참고:** 이 규칙 단위 옵션을 지정하면 공유 `settings` 설정보다 우선 적용됩니다.
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/gating.md b/src/content/reference/eslint-plugin-react-hooks/lints/gating.md
index 3bd662a86..959b00a57 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/gating.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/gating.md
@@ -4,53 +4,53 @@ title: gating
-Validates configuration of [gating mode](/reference/react-compiler/gating).
+[게이팅 모드](/reference/react-compiler/gating)의 설정을 검증합니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 사항 {/*rule-details*/}
-Gating mode lets you gradually adopt React Compiler by marking specific components for optimization. This rule ensures your gating configuration is valid so the compiler knows which components to process.
+게이팅 모드는 특정 컴포넌트를 최적화 대상으로 표시하여 React 컴파일러를 점진적으로 도입할 수 있게 해줍니다. 이 규칙은 컴파일러가 어떤 컴포넌트를 처리할지 알 수 있도록 게이팅 설정이 유효한지 확인합니다.
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-Examples of incorrect code for this rule:
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
-// ❌ Missing required fields
+// ❌ 필수 필드 누락
module.exports = {
plugins: [
['babel-plugin-react-compiler', {
gating: {
importSpecifierName: '__experimental_useCompiler'
- // Missing 'source' field
+ // 'source' 필드 누락
}
}]
]
};
-// ❌ Invalid gating type
+// ❌ 유효하지 않은 게이팅 타입
module.exports = {
plugins: [
['babel-plugin-react-compiler', {
- gating: '__experimental_useCompiler' // Should be object
+ gating: '__experimental_useCompiler' // 객체여야 함
}]
]
};
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
-// ✅ Complete gating configuration
+// ✅ 완전한 게이팅 설정
module.exports = {
plugins: [
['babel-plugin-react-compiler', {
gating: {
- importSpecifierName: 'isCompilerEnabled', // exported function name
- source: 'featureFlags' // module name
+ importSpecifierName: 'isCompilerEnabled', // 내보낸 함수 이름
+ source: 'featureFlags' // 모듈 이름
}
}]
]
@@ -61,11 +61,11 @@ export function isCompilerEnabled() {
// ...
}
-// ✅ No gating (compile everything)
+// ✅ 게이팅 없음 (모든 것을 컴파일)
module.exports = {
plugins: [
['babel-plugin-react-compiler', {
- // No gating field - compiles all components
+ // gating 필드 없음 - 모든 컴포넌트를 컴파일
}]
]
};
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/globals.md b/src/content/reference/eslint-plugin-react-hooks/lints/globals.md
index fe0cbe008..62c1d61e0 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/globals.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/globals.md
@@ -4,55 +4,55 @@ title: globals
-Validates against assignment/mutation of globals during render, part of ensuring that [side effects must run outside of render](/reference/rules/components-and-hooks-must-be-pure#side-effects-must-run-outside-of-render).
+렌더링 중 전역 변수의 할당/변이를 검증합니다. 이는 [사이드 이펙트는 렌더링 외부에서 실행되어야 한다는](/reference/rules/components-and-hooks-must-be-pure#side-effects-must-run-outside-of-render) 규칙을 보완합니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 사항 {/*rule-details*/}
-Global variables exist outside React's control. When you modify them during render, you break React's assumption that rendering is pure. This can cause components to behave differently in development vs production, break Fast Refresh, and make your app impossible to optimize with features like React Compiler.
+전역 변수는 React의 제어 범위 밖에 존재합니다. 렌더링 중에 전역 변수를 수정하면 렌더링이 순수하다는 React의 가정을 깨뜨립니다. 이로 인해 컴포넌트가 개발 환경과 프로덕션 환경에서 다르게 동작하거나, Fast Refresh가 중단되거나, React 컴파일러 같은 기능으로 앱을 최적화할 수 없게 됩니다.
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-Examples of incorrect code for this rule:
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
-// ❌ Global counter
+// ❌ 전역 카운터
let renderCount = 0;
function Component() {
- renderCount++; // Mutating global
+ renderCount++; // 전역 변수 변이
return Count: {renderCount}
;
}
-// ❌ Modifying window properties
+// ❌ window 프로퍼티 수정
function Component({userId}) {
- window.currentUser = userId; // Global mutation
+ window.currentUser = userId; // 전역 변이
return User: {userId}
;
}
-// ❌ Global array push
+// ❌ 전역 배열 push
const events = [];
function Component({event}) {
- events.push(event); // Mutating global array
+ events.push(event); // 전역 배열 변이
return Events: {events.length}
;
}
-// ❌ Cache manipulation
+// ❌ 캐시 조작
const cache = {};
function Component({id}) {
if (!cache[id]) {
- cache[id] = fetchData(id); // Modifying cache during render
+ cache[id] = fetchData(id); // 렌더링 중 캐시 수정
}
return {cache[id]}
;
}
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
-// ✅ Use state for counters
+// ✅ 카운터에는 state 사용
function Component() {
const [clickCount, setClickCount] = useState(0);
@@ -67,16 +67,16 @@ function Component() {
);
}
-// ✅ Use context for global values
+// ✅ 전역 값에는 context 사용
function Component() {
const user = useContext(UserContext);
return User: {user.id}
;
}
-// ✅ Synchronize external state with React
+// ✅ 외부 state를 React와 동기화
function Component({title}) {
useEffect(() => {
- document.title = title; // OK in effect
+ document.title = title; // Effect 내에서는 OK
}, [title]);
return Page: {title}
;
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/immutability.md b/src/content/reference/eslint-plugin-react-hooks/lints/immutability.md
index 5f91e6eda..b096b2cd9 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/immutability.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/immutability.md
@@ -4,85 +4,85 @@ title: immutability
-Validates against mutating props, state, and other values that [are immutable](/reference/rules/components-and-hooks-must-be-pure#props-and-state-are-immutable).
+[불변인](/reference/rules/components-and-hooks-must-be-pure#props-and-state-are-immutable) props, state 및 기타 값을 변이하는 것을 검증합니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 사항 {/*rule-details*/}
-A component’s props and state are immutable snapshots. Never mutate them directly. Instead, pass new props down, and use the setter function from `useState`.
+컴포넌트의 props와 state는 불변 스냅샷입니다. 절대 직접 변이하지 마세요. 대신 새로운 props를 전달하고, `useState`의 setter 함수를 사용하세요.
-## Common Violations {/*common-violations*/}
+## 일반적인 위반 사례 {/*common-violations*/}
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
```js
-// ❌ Array push mutation
+// ❌ 배열 push 변이
function Component() {
const [items, setItems] = useState([1, 2, 3]);
const addItem = () => {
- items.push(4); // Mutating!
- setItems(items); // Same reference, no re-render
+ items.push(4); // 변이!
+ setItems(items); // 같은 참조, 리렌더링 안 됨
};
}
-// ❌ Object property assignment
+// ❌ 객체 프로퍼티 할당
function Component() {
const [user, setUser] = useState({name: 'Alice'});
const updateName = () => {
- user.name = 'Bob'; // Mutating!
- setUser(user); // Same reference
+ user.name = 'Bob'; // 변이!
+ setUser(user); // 같은 참조
};
}
-// ❌ Sort without spreading
+// ❌ 스프레드 없이 정렬
function Component() {
const [items, setItems] = useState([3, 1, 2]);
const sortItems = () => {
- setItems(items.sort()); // sort mutates!
+ setItems(items.sort()); // sort는 변이함!
};
}
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
```js
-// ✅ Create new array
+// ✅ 새 배열 생성
function Component() {
const [items, setItems] = useState([1, 2, 3]);
const addItem = () => {
- setItems([...items, 4]); // New array
+ setItems([...items, 4]); // 새 배열
};
}
-// ✅ Create new object
+// ✅ 새 객체 생성
function Component() {
const [user, setUser] = useState({name: 'Alice'});
const updateName = () => {
- setUser({...user, name: 'Bob'}); // New object
+ setUser({...user, name: 'Bob'}); // 새 객체
};
}
```
-## Troubleshooting {/*troubleshooting*/}
+## 문제 해결 {/*troubleshooting*/}
-### I need to add items to an array {/*add-items-array*/}
+### 배열에 항목을 추가해야 하는 경우 {/*add-items-array*/}
-Mutating arrays with methods like `push()` won't trigger re-renders:
+`push()` 같은 메서드로 배열을 변이하면 리렌더링이 트리거되지 않습니다.
```js
-// ❌ Wrong: Mutating the array
+// ❌ 잘못된 예: 배열 변이
function TodoList() {
const [todos, setTodos] = useState([]);
const addTodo = (id, text) => {
todos.push({id, text});
- setTodos(todos); // Same array reference!
+ setTodos(todos); // 같은 배열 참조!
};
return (
@@ -93,16 +93,16 @@ function TodoList() {
}
```
-Create a new array instead:
+대신 새 배열을 생성하세요.
```js
-// ✅ Better: Create a new array
+// ✅ 더 나은 방법: 새 배열 생성
function TodoList() {
const [todos, setTodos] = useState([]);
const addTodo = (id, text) => {
setTodos([...todos, {id, text}]);
- // Or: setTodos(todos => [...todos, {id: Date.now(), text}])
+ // 또는: setTodos(todos => [...todos, {id: Date.now(), text}])
};
return (
@@ -113,12 +113,12 @@ function TodoList() {
}
```
-### I need to update nested objects {/*update-nested-objects*/}
+### 중첩된 객체를 업데이트해야 하는 경우 {/*update-nested-objects*/}
-Mutating nested properties doesn't trigger re-renders:
+중첩된 프로퍼티를 변이하면 리렌더링이 트리거되지 않습니다.
```js
-// ❌ Wrong: Mutating nested object
+// ❌ 잘못된 예: 중첩된 객체 변이
function UserProfile() {
const [user, setUser] = useState({
name: 'Alice',
@@ -129,16 +129,16 @@ function UserProfile() {
});
const toggleTheme = () => {
- user.settings.theme = 'dark'; // Mutation!
- setUser(user); // Same object reference
+ user.settings.theme = 'dark'; // 변이!
+ setUser(user); // 같은 객체 참조
};
}
```
-Spread at each level that needs updating:
+업데이트가 필요한 각 레벨에서 스프레드하세요.
```js
-// ✅ Better: Create new objects at each level
+// ✅ 더 나은 방법: 각 레벨에서 새 객체 생성
function UserProfile() {
const [user, setUser] = useState({
name: 'Alice',
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/incompatible-library.md b/src/content/reference/eslint-plugin-react-hooks/lints/incompatible-library.md
index e057e1978..140c9c369 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/incompatible-library.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/incompatible-library.md
@@ -4,59 +4,59 @@ title: incompatible-library
-Validates against usage of libraries which are incompatible with memoization (manual or automatic).
+메모이제이션(수동 또는 자동)과 호환되지 않는 라이브러리 사용에 대해 검증합니다.
-These libraries were designed before React's memoization rules were fully documented. They made the correct choices at the time to optimize for ergonomic ways to keep components just the right amount of reactive as app state changes. While these legacy patterns worked, we have since discovered that it's incompatible with React's programming model. We will continue working with library authors to migrate these libraries to use patterns that follow the Rules of React.
+이러한 라이브러리는 React의 메모이제이션 규칙이 완전히 문서화되기 전에 설계되었습니다. 당시에는 앱 상태가 변경될 때 컴포넌트가 적절한 반응성을 유지하도록 인체공학적인 방법을 최적화하기 위해 올바른 선택을 했습니다. 이러한 레거시 패턴은 작동했지만, 이후 React의 프로그래밍 모델과 호환되지 않는다는 것을 발견했습니다. React 규칙을 따르는 패턴을 사용하도록 이러한 라이브러리를 마이그레이션하기 위해 라이브러리 작성자와 계속 협력하고 있습니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 정보 {/*rule-details*/}
-Some libraries use patterns that aren't supported by React. When the linter detects usages of these APIs from a [known list](https://github.com/facebook/react/blob/main/compiler/packages/babel-plugin-react-compiler/src/HIR/DefaultModuleTypeProvider.ts), it flags them under this rule. This means that React Compiler can automatically skip over components that use these incompatible APIs, in order to avoid breaking your app.
+일부 라이브러리는 React에서 지원하지 않는 패턴을 사용합니다. 린터가 [알려진 목록](https://github.com/facebook/react/blob/main/compiler/packages/babel-plugin-react-compiler/src/HIR/DefaultModuleTypeProvider.ts)에서 이러한 API의 사용을 감지하면 이 규칙에 따라 플래그를 지정합니다. 이는 React 컴파일러가 앱을 손상시키지 않기 위해 이러한 호환되지 않는 API를 사용하는 컴포넌트를 자동으로 건너뛸 수 있음을 의미합니다.
```js
-// Example of how memoization breaks with these libraries
+// 이러한 라이브러리로 메모이제이션이 깨지는 예시
function Form() {
const { watch } = useForm();
- // ❌ This value will never update, even when 'name' field changes
+ // ❌ 'name' 필드가 변경되어도 이 값은 절대 업데이트되지 않습니다
const name = useMemo(() => watch('name'), [watch]);
- return Name: {name}
; // UI appears "frozen"
+ return Name: {name}
; // UI가 "얼어붙은" 것처럼 보입니다
}
```
-React Compiler automatically memoizes values following the Rules of React. If something breaks with manual `useMemo`, it will also break the compiler's automatic optimization. This rule helps identify these problematic patterns.
+React 컴파일러는 React 규칙을 따라 값을 자동으로 메모이제이션합니다. 수동 `useMemo`로 문제가 발생하면 컴파일러의 자동 최적화도 깨집니다. 이 규칙은 이러한 문제가 있는 패턴을 식별하는 데 도움이 됩니다.
-#### Designing APIs that follow the Rules of React {/*designing-apis-that-follow-the-rules-of-react*/}
+#### React 규칙을 따르는 API 설계하기 {/*designing-apis-that-follow-the-rules-of-react*/}
-One question to think about when designing a library API or hook is whether calling the API can be safely memoized with `useMemo`. If it can't, then both manual and React Compiler memoizations will break your user's code.
+라이브러리 API나 Hook을 설계할 때 고려해야 할 질문 중 하나는 API 호출을 `useMemo`로 안전하게 메모이제이션할 수 있는지 여부입니다. 그렇지 않다면 수동 메모이제이션과 React 컴파일러 메모이제이션 모두 사용자의 코드를 손상시킬 것입니다.
-For example, one such incompatible pattern is "interior mutability". Interior mutability is when an object or function keeps its own hidden state that changes over time, even though the reference to it stays the same. Think of it like a box that looks the same on the outside but secretly rearranges its contents. React can't tell anything changed because it only checks if you gave it a different box, not what's inside. This breaks memoization, since React relies on the outer object (or function) changing if part of its value has changed.
+예를 들어, 이러한 호환되지 않는 패턴 중 하나는 "내부 가변성"입니다. 내부 가변성은 객체나 함수가 참조는 동일하게 유지되지만 시간이 지남에 따라 변경되는 자체 숨겨진 상태를 유지하는 것을 말합니다. 외부에서는 동일해 보이지만 내용물을 은밀하게 재배치하는 상자라고 생각하면 됩니다. React는 다른 상자를 받았는지만 확인하고 안에 무엇이 들어 있는지는 확인하지 않기 때문에 변경 사항을 알 수 없습니다. 이는 메모이제이션을 깨뜨리는데, React는 값의 일부가 변경된 경우 외부 객체(또는 함수)가 변경되는 것에 의존하기 때문입니다.
-As a rule of thumb, when designing React APIs, think about whether `useMemo` would break it:
+React API를 설계할 때의 경험 법칙으로, `useMemo`가 이를 깨뜨릴지 생각해보세요.
```js
function Component() {
const { someFunction } = useLibrary();
- // it should always be safe to memoize functions like this
+ // 이와 같은 함수를 메모이제이션하는 것은 항상 안전해야 합니다
const result = useMemo(() => someFunction(), [someFunction]);
}
```
-Instead, design APIs that return immutable state and use explicit update functions:
+대신, 불변 상태를 반환하고 명시적인 업데이트 함수를 사용하는 API를 설계하세요.
```js
-// ✅ Good: Return immutable state that changes reference when updated
+// ✅ 좋은 예시: 업데이트될 때 참조가 변경되는 불변 상태를 반환
function Component() {
const { field, updateField } = useLibrary();
- // this is always safe to memo
+ // 이것은 항상 메모이제이션하기에 안전합니다
const greeting = useMemo(() => `Hello, ${field.name}!`, [field.name]);
return (
@@ -73,15 +73,15 @@ function Component() {
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-Examples of incorrect code for this rule:
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
// ❌ react-hook-form `watch`
function Component() {
const {watch} = useForm();
- const value = watch('field'); // Interior mutability
+ const value = watch('field'); // 내부 가변성
return {value}
;
}
@@ -92,7 +92,7 @@ function Component({data}) {
columns,
getCoreRowModel: getCoreRowModel(),
});
- // table instance uses interior mutability
+ // table 인스턴스가 내부 가변성을 사용합니다
return ;
}
```
@@ -101,24 +101,24 @@ function Component({data}) {
#### MobX {/*mobx*/}
-MobX patterns like `observer` also break memoization assumptions, but the linter does not yet detect them. If you rely on MobX and find that your app doesn't work with React Compiler, you may need to use the `"use no memo" directive`.
+`observer`와 같은 MobX 패턴도 메모이제이션 가정을 깨뜨리지만, 린터는 아직 이를 감지하지 못합니다. MobX에 의존하고 있고 React 컴파일러에서 앱이 작동하지 않는다면 `"use no memo"` 지시어를 사용해야 할 수 있습니다.
```js
// ❌ MobX `observer`
const Component = observer(() => {
const [timer] = useState(() => new Timer());
- return Seconds passed: {timer.secondsPassed} ;
+ return 경과된 시간: {timer.secondsPassed} ;
});
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
-// ✅ For react-hook-form, use `useWatch`:
+// ✅ react-hook-form의 경우 `useWatch`를 사용하세요
function Component() {
const {register, control} = useForm();
const watchedValue = useWatch({
@@ -129,10 +129,10 @@ function Component() {
return (
<>
Current value: {watchedValue}
+ 현재 값: {watchedValue}
);
}
```
-Some other libraries do not yet have alternative APIs that are compatible with React's memoization model. If the linter doesn't automatically skip over your components or hooks that call these APIs, please [file an issue](https://github.com/facebook/react/issues) so we can add it to the linter.
+일부 다른 라이브러리는 아직 React의 메모이제이션 모델과 호환되는 대체 API가 없습니다. 린터가 이러한 API를 호출하는 컴포넌트나 Hook을 자동으로 건너뛰지 않는다면 [이슈를 제출](https://github.com/facebook/react/issues)하여 린터에 추가할 수 있도록 해주세요.
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/preserve-manual-memoization.md b/src/content/reference/eslint-plugin-react-hooks/lints/preserve-manual-memoization.md
index 1016bad37..267391c26 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/preserve-manual-memoization.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/preserve-manual-memoization.md
@@ -4,70 +4,70 @@ title: preserve-manual-memoization
-Validates that existing manual memoization is preserved by the compiler. React Compiler will only compile components and hooks if its inference [matches or exceeds the existing manual memoization](/learn/react-compiler/introduction#what-should-i-do-about-usememo-usecallback-and-reactmemo).
+컴파일러가 기존 수동 메모이제이션을 보존하는지 검증합니다. React 컴파일러는 추론이 [기존 수동 메모이제이션과 일치하거나 이를 초과하는 경우](/learn/react-compiler/introduction#what-should-i-do-about-usememo-usecallback-and-reactmemo)에만 컴포넌트와 Hook을 컴파일합니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 정보 {/*rule-details*/}
-React Compiler preserves your existing `useMemo`, `useCallback`, and `React.memo` calls. If you've manually memoized something, the compiler assumes you had a good reason and won't remove it. However, incomplete dependencies prevent the compiler from understanding your code's data flow and applying further optimizations.
+React 컴파일러는 기존의 `useMemo`, `useCallback` 및 `React.memo` 호출을 보존합니다. 수동으로 메모이제이션한 경우 컴파일러는 타당한 이유가 있다고 가정하고 제거하지 않습니다. 그러나 불완전한 의존성은 컴파일러가 코드의 데이터 흐름을 이해하고 추가 최적화를 적용하는 것을 방해합니다.
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-Examples of incorrect code for this rule:
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
-// ❌ Missing dependencies in useMemo
+// ❌ useMemo에 의존성 누락
function Component({ data, filter }) {
const filtered = useMemo(
() => data.filter(filter),
- [data] // Missing 'filter' dependency
+ [data] // 'filter' 의존성 누락
);
return
;
}
-// ❌ Missing dependencies in useCallback
+// ❌ useCallback에 의존성 누락
function Component({ onUpdate, value }) {
const handleClick = useCallback(() => {
onUpdate(value);
- }, [onUpdate]); // Missing 'value'
+ }, [onUpdate]); // 'value' 누락
return Update ;
}
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
-// ✅ Complete dependencies
+// ✅ 완전한 의존성
function Component({ data, filter }) {
const filtered = useMemo(
() => data.filter(filter),
- [data, filter] // All dependencies included
+ [data, filter] // 모든 의존성 포함
);
return
;
}
-// ✅ Or let the compiler handle it
+// ✅ 또는 컴파일러가 처리하도록 함
function Component({ data, filter }) {
- // No manual memoization needed
+ // 수동 메모이제이션 불필요
const filtered = data.filter(filter);
return
;
}
```
-## Troubleshooting {/*troubleshooting*/}
+## 문제 해결 {/*troubleshooting*/}
-### Should I remove my manual memoization? {/*remove-manual-memoization*/}
+### 수동 메모이제이션을 제거해야 하나요? {/*remove-manual-memoization*/}
-You might wonder if React Compiler makes manual memoization unnecessary:
+React 컴파일러가 수동 메모이제이션을 불필요하게 만드는지 궁금할 수 있습니다.
```js
-// Do I still need this?
+// 이게 여전히 필요한가요?
function Component({items, sortBy}) {
const sorted = useMemo(() => {
return [...items].sort((a, b) => {
@@ -79,10 +79,10 @@ function Component({items, sortBy}) {
}
```
-You can safely remove it if using React Compiler:
+React 컴파일러를 사용하는 경우 안전하게 제거할 수 있습니다.
```js
-// ✅ Better: Let the compiler optimize
+// ✅ 더 나은 방법: 컴파일러가 최적화하도록 함
function Component({items, sortBy}) {
const sorted = [...items].sort((a, b) => {
return a[sortBy] - b[sortBy];
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/purity.md b/src/content/reference/eslint-plugin-react-hooks/lints/purity.md
index ce9ec5ac1..a683512a8 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/purity.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/purity.md
@@ -4,67 +4,67 @@ title: purity
-Validates that [components/hooks are pure](/reference/rules/components-and-hooks-must-be-pure) by checking that they do not call known-impure functions.
+알려진 순수하지 않은 함수를 호출하지 않는지 확인하여 [컴포넌트와 Hook이 순수한지](/reference/rules/components-and-hooks-must-be-pure) 검증합니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 정보 {/*rule-details*/}
-React components must be pure functions - given the same props, they should always return the same JSX. When components use functions like `Math.random()` or `Date.now()` during render, they produce different output each time, breaking React's assumptions and causing bugs like hydration mismatches, incorrect memoization, and unpredictable behavior.
+React 컴포넌트는 순수 함수여야 합니다. 동일한 props가 주어지면 항상 동일한 JSX를 반환해야 합니다. 컴포넌트가 렌더링 중에 `Math.random()`이나 `Date.now()`와 같은 함수를 사용하면 매번 다른 출력을 생성하여 React의 가정을 깨뜨리고 하이드레이션 불일치, 잘못된 메모이제이션, 예측할 수 없는 동작과 같은 버그를 발생시킵니다.
-## Common Violations {/*common-violations*/}
+## 일반적인 위반 사례 {/*common-violations*/}
-In general, any API that returns a different value for the same inputs violates this rule. Usual examples include:
+일반적으로 동일한 입력에 대해 다른 값을 반환하는 API는 이 규칙을 위반합니다. 일반적인 예시는 다음과 같습니다.
- `Math.random()`
- `Date.now()` / `new Date()`
- `crypto.randomUUID()`
- `performance.now()`
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-Examples of incorrect code for this rule:
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
-// ❌ Math.random() in render
+// ❌ 렌더링 중 Math.random() 사용
function Component() {
- const id = Math.random(); // Different every render
+ const id = Math.random(); // 렌더링할 때마다 다름
return Content
;
}
-// ❌ Date.now() for values
+// ❌ 값으로 Date.now() 사용
function Component() {
- const timestamp = Date.now(); // Changes every render
- return Created at: {timestamp}
;
+ const timestamp = Date.now(); // 렌더링할 때마다 변경됨
+ return 생성 시각: {timestamp}
;
}
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
-// ✅ Stable IDs from initial state
+// ✅ 초기 상태에서 안정적인 ID 생성
function Component() {
const [id] = useState(() => crypto.randomUUID());
return Content
;
}
```
-## Troubleshooting {/*troubleshooting*/}
+## 문제 해결 {/*troubleshooting*/}
-### I need to show the current time {/*current-time*/}
+### 현재 시간을 표시해야 합니다 {/*current-time*/}
-Calling `Date.now()` during render makes your component impure:
+렌더링 중에 `Date.now()`를 호출하면 컴포넌트가 순수하지 않게 됩니다.
```js
-// ❌ Wrong: Time changes every render
+// ❌ 잘못된 예시: 렌더링할 때마다 시간이 변경됨
function Clock() {
- return Current time: {Date.now()}
;
+ return 현재 시각: {Date.now()}
;
}
```
-Instead, [move the impure function outside of render](/reference/rules/components-and-hooks-must-be-pure#components-and-hooks-must-be-idempotent):
+대신 [순수하지 않은 함수를 렌더링 외부로 이동하세요](/reference/rules/components-and-hooks-must-be-pure#components-and-hooks-must-be-idempotent).
```js
function Clock() {
@@ -78,6 +78,6 @@ function Clock() {
return () => clearInterval(interval);
}, []);
- return Current time: {time}
;
+ return 현재 시각: {time}
;
}
```
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/refs.md b/src/content/reference/eslint-plugin-react-hooks/lints/refs.md
index 3108fdd89..71cf38b8f 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/refs.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/refs.md
@@ -4,83 +4,83 @@ title: refs
-Validates correct usage of refs, not reading/writing during render. See the "pitfalls" section in [`useRef()` usage](/reference/react/useRef#usage).
+렌더링 중에 읽기/쓰기를 하지 않는 ref의 올바른 사용법을 검증합니다. [`useRef()` 사용법](/reference/react/useRef#usage)의 "주의하세요!" 섹션을 참고하세요.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 정보 {/*rule-details*/}
-Refs hold values that aren't used for rendering. Unlike state, changing a ref doesn't trigger a re-render. Reading or writing `ref.current` during render breaks React's expectations. Refs might not be initialized when you try to read them, and their values can be stale or inconsistent.
+Ref는 렌더링에 사용되지 않는 값을 보유합니다. State와 달리 ref를 변경해도 재렌더링이 트리거되지 않습니다. 렌더링 중에 `ref.current`를 읽거나 쓰는 것은 React의 예상을 깨뜨립니다. Ref는 읽으려고 할 때 초기화되지 않았을 수 있으며, 그 값은 오래되었거나 일관되지 않을 수 있습니다.
-## How It Detects Refs {/*how-it-detects-refs*/}
+## Ref 감지 방법 {/*how-it-detects-refs*/}
-The lint only applies these rules to values it knows are refs. A value is inferred as a ref when the compiler sees any of the following patterns:
+린트는 ref로 알고 있는 값에만 이러한 규칙을 적용합니다. 값은 컴파일러가 다음 패턴 중 하나를 발견하면 ref로 추론됩니다.
-- Returned from `useRef()` or `React.createRef()`.
+- `useRef()` 또는 `React.createRef()`에서 반환된 값
```js
const scrollRef = useRef(null);
```
-- An identifier named `ref` or ending in `Ref` that reads from or writes to `.current`.
+- `ref`로 명명되거나 `Ref`로 끝나는 식별자가 `.current`를 읽거나 쓰는 경우
```js
buttonRef.current = node;
```
-- Passed through a JSX `ref` prop (for example `
`).
+- JSX `ref` prop을 통해 전달된 경우 (예: `
`)
```jsx
{value}
;
}
-// ❌ Modifying ref during render
+// ❌ 렌더링 중에 ref 수정
function Component({value}) {
const ref = useRef(null);
- ref.current = value; // Don't modify during render
+ ref.current = value; // 렌더링 중에 수정하지 마세요
return
;
}
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
-// ✅ Read ref in effects/handlers
+// ✅ Effect/핸들러에서 ref 읽기
function Component() {
const ref = useRef(null);
useEffect(() => {
if (ref.current) {
- console.log(ref.current.offsetWidth); // OK in effect
+ console.log(ref.current.offsetWidth); // Effect에서는 OK
}
});
return
;
}
-// ✅ Use state for UI values
+// ✅ UI 값에는 state 사용
function Component() {
const [count, setCount] = useState(0);
@@ -91,25 +91,25 @@ function Component() {
);
}
-// ✅ Lazy initialization of ref value
+// ✅ ref 값의 지연 초기화
function Component() {
const ref = useRef(null);
- // Initialize only once on first use
+ // 첫 사용 시 한 번만 초기화
if (ref.current === null) {
- ref.current = expensiveComputation(); // OK - lazy initialization
+ ref.current = expensiveComputation(); // OK - 지연 초기화
}
const handleClick = () => {
- console.log(ref.current); // Use the initialized value
+ console.log(ref.current); // 초기화된 값 사용
};
return Click ;
}
```
-## Troubleshooting {/*troubleshooting*/}
+## 문제 해결 {/*troubleshooting*/}
-### The lint flagged my plain object with `.current` {/*plain-object-current*/}
+### 린트가 `.current`가 있는 일반 객체를 플래그 지정했습니다 {/*plain-object-current*/}
-The name heuristic intentionally treats `ref.current` and `fooRef.current` as real refs. If you're modeling a custom container object, pick a different name (for example, `box`) or move the mutable value into state. Renaming avoids the lint because the compiler stops inferring it as a ref.
+이름 휴리스틱은 의도적으로 `ref.current`와 `fooRef.current`를 실제 ref로 취급합니다. 커스텀 컨테이너 객체를 모델링하는 경우 다른 이름(예: `box`)을 선택하거나 가변 값을 state로 이동하세요. 이름을 변경하면 컴파일러가 ref로 추론하지 않기 때문에 린트를 피할 수 있습니다.
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/rules-of-hooks.md b/src/content/reference/eslint-plugin-react-hooks/lints/rules-of-hooks.md
index 56a9d74be..42cfaa8ed 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/rules-of-hooks.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/rules-of-hooks.md
@@ -4,89 +4,89 @@ title: rules-of-hooks
-Validates that components and hooks follow the [Rules of Hooks](/reference/rules/rules-of-hooks).
+컴포넌트와 Hook이 [Hook의 규칙](/reference/rules/rules-of-hooks)을 따르는지 검증합니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 사항 {/*rule-details*/}
-React relies on the order in which hooks are called to correctly preserve state between renders. Each time your component renders, React expects the exact same hooks to be called in the exact same order. When hooks are called conditionally or in loops, React loses track of which state corresponds to which hook call, leading to bugs like state mismatches and "Rendered fewer/more hooks than expected" errors.
+React는 Hook이 호출되는 순서에 의존하여 렌더링 간에 state를 올바르게 보존합니다. 컴포넌트가 렌더링될 때마다 React는 정확히 같은 Hook이 정확히 같은 순서로 호출되기를 기대합니다. Hook이 조건부로 호출되거나 루프에서 호출되면 React는 어떤 state가 어떤 Hook 호출에 해당하는지 추적할 수 없게 되어 state 불일치와 "Rendered fewer/more hooks than expected" 오류 같은 버그가 발생합니다.
-## Common Violations {/*common-violations*/}
+## 일반적인 위반 사례 {/*common-violations*/}
-These patterns violate the Rules of Hooks:
+다음 패턴들은 Hook의 규칙을 위반합니다.
-- **Hooks in conditions** (`if`/`else`, ternary, `&&`/`||`)
-- **Hooks in loops** (`for`, `while`, `do-while`)
-- **Hooks after early returns**
-- **Hooks in callbacks/event handlers**
-- **Hooks in async functions**
-- **Hooks in class methods**
-- **Hooks at module level**
+- **조건문의 Hook** (`if`/`else`, 삼항 연산자, `&&`/`||`)
+- **루프의 Hook** (`for`, `while`, `do-while`)
+- **조기 return 이후의 Hook**
+- **콜백/이벤트 핸들러의 Hook**
+- **async 함수의 Hook**
+- **클래스 메서드의 Hook**
+- **모듈 레벨의 Hook**
-### `use` hook {/*use-hook*/}
+### `use` Hook {/*use-hook*/}
-The `use` hook is different from other React hooks. You can call it conditionally and in loops:
+`use` Hook은 다른 React Hook과 다릅니다. 조건부로 호출하거나 루프에서 호출할 수 있습니다.
```js
-// ✅ `use` can be conditional
+// ✅ `use`는 조건문에서 호출 가능
if (shouldFetch) {
const data = use(fetchPromise);
}
-// ✅ `use` can be in loops
+// ✅ `use`는 루프에서 호출 가능
for (const promise of promises) {
results.push(use(promise));
}
```
-However, `use` still has restrictions:
-- Can't be wrapped in try/catch
-- Must be called inside a component or hook
+하지만 `use`에는 여전히 제약이 있습니다.
+- `try`/`catch`로 감쌀 수 없습니다.
+- 컴포넌트나 Hook 내부에서 호출해야 합니다.
-Learn more: [`use` API Reference](/reference/react/use)
+더 알아보기: [`use` API 레퍼런스](/reference/react/use)
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-Examples of incorrect code for this rule:
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
-// ❌ Hook in condition
+// ❌ 조건문의 Hook
if (isLoggedIn) {
const [user, setUser] = useState(null);
}
-// ❌ Hook after early return
+// ❌ 조기 return 이후의 Hook
if (!data) return {
const [clicked, setClicked] = useState(false);
}}/>
-// ❌ `use` in try/catch
+// ❌ try/catch의 `use`
try {
const data = use(promise);
} catch (e) {
- // error handling
+ // 오류 처리
}
-// ❌ Hook at module level
-const globalState = useState(0); // Outside component
+// ❌ 모듈 레벨의 Hook
+const globalState = useState(0); // 컴포넌트 외부
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
function Component({ isSpecial, shouldFetch, fetchPromise }) {
- // ✅ Hooks at top level
+ // ✅ 최상위 레벨의 Hook
const [count, setCount] = useState(0);
const [name, setName] = useState('');
@@ -95,7 +95,7 @@ function Component({ isSpecial, shouldFetch, fetchPromise }) {
}
if (shouldFetch) {
- // ✅ `use` can be conditional
+ // ✅ `use`는 조건문에서 호출 가능
const data = use(fetchPromise);
return {data}
;
}
@@ -104,14 +104,14 @@ function Component({ isSpecial, shouldFetch, fetchPromise }) {
}
```
-## Troubleshooting {/*troubleshooting*/}
+## 문제 해결 {/*troubleshooting*/}
-### I want to fetch data based on some condition {/*conditional-data-fetching*/}
+### 조건에 따라 데이터를 가져오고 싶은 경우 {/*conditional-data-fetching*/}
-You're trying to conditionally call useEffect:
+`useEffect`를 조건부로 호출하려고 합니다.
```js
-// ❌ Conditional hook
+// ❌ 조건부 Hook
if (isLoggedIn) {
useEffect(() => {
fetchUserData();
@@ -119,10 +119,10 @@ if (isLoggedIn) {
}
```
-Call the hook unconditionally, check condition inside:
+Hook을 무조건 호출하고 내부에서 조건을 확인하세요.
```js
-// ✅ Condition inside hook
+// ✅ Hook 내부의 조건
useEffect(() => {
if (isLoggedIn) {
fetchUserData();
@@ -132,18 +132,18 @@ useEffect(() => {
-There are better ways to fetch data rather than in a useEffect. Consider using React Query, useSWR, or React Router 6.4+ for data fetching. These solutions handle deduplicating requests, caching responses, and avoiding network waterfalls.
+`useEffect`에서 데이터를 가져오는Fetch 것보다 더 나은 방법이 있습니다. 데이터 가져오기에는 React Query, useSWR 또는 React Router 6.4+를 사용하는 것을 고려하세요. 이러한 솔루션은 요청 중복 제거, 응답 캐싱, 네트워크 워터폴 방지를 처리합니다.
-Learn more: [Fetching Data](/learn/synchronizing-with-effects#fetching-data)
+더 알아보기: [데이터 가져오기](/learn/synchronizing-with-effects#fetching-data)
-### I need different state for different scenarios {/*conditional-state-initialization*/}
+### 다른 시나리오에 따라 다른 state가 필요한 경우 {/*conditional-state-initialization*/}
-You're trying to conditionally initialize state:
+state를 조건부로 초기화하려고 합니다.
```js
-// ❌ Conditional state
+// ❌ 조건부 state
if (userType === 'admin') {
const [permissions, setPermissions] = useState(adminPerms);
} else {
@@ -151,18 +151,18 @@ if (userType === 'admin') {
}
```
-Always call useState, conditionally set the initial value:
+항상 `useState`를 호출하고 초기값을 조건부로 설정하세요.
```js
-// ✅ Conditional initial value
+// ✅ 조건부 초기값
const [permissions, setPermissions] = useState(
userType === 'admin' ? adminPerms : userPerms
);
```
-## Options {/*options*/}
+## 옵션 {/*options*/}
-You can configure custom effect hooks using shared ESLint settings (available in `eslint-plugin-react-hooks` 6.1.1 and later):
+공유 ESLint 설정을 사용하여 커스텀 Effect Hook을 설정할 수 있습니다 (`eslint-plugin-react-hooks` 6.1.1 이상에서 사용 가능).
```js
{
@@ -174,6 +174,6 @@ You can configure custom effect hooks using shared ESLint settings (available in
}
```
-- `additionalEffectHooks`: Regex pattern matching custom hooks that should be treated as effects. This allows `useEffectEvent` and similar event functions to be called from your custom effect hooks.
+- `additionalEffectHooks`: Effect로 취급되어야 하는 커스텀 Hook을 일치시키는 정규식 패턴입니다. 이를 통해 `useEffectEvent` 및 유사한 이벤트 함수를 커스텀 Effect Hook에서 호출할 수 있습니다.
-This shared configuration is used by both `rules-of-hooks` and `exhaustive-deps` rules, ensuring consistent behavior across all hook-related linting.
+이 공유 설정은 `rules-of-hooks`와 `exhaustive-deps` 규칙 모두에서 사용되어 모든 Hook 관련 린트에서 일관된 동작을 보장합니다.
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/set-state-in-effect.md b/src/content/reference/eslint-plugin-react-hooks/lints/set-state-in-effect.md
index 64fa5c655..6eeabfde0 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/set-state-in-effect.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/set-state-in-effect.md
@@ -4,60 +4,60 @@ title: set-state-in-effect
-Validates against calling setState synchronously in an effect, which can lead to re-renders that degrade performance.
+Effect에서 `setState`를 동기적으로 호출하는 것에 대해 검증합니다. 이는 성능을 저하시키는 재렌더링으로 이어질 수 있습니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 정보 {/*rule-details*/}
-Setting state immediately inside an effect forces React to restart the entire render cycle. When you update state in an effect, React must re-render your component, apply changes to the DOM, and then run effects again. This creates an extra render pass that could have been avoided by transforming data directly during render or deriving state from props. Transform data at the top level of your component instead. This code will naturally re-run when props or state change without triggering additional render cycles.
+Effect 내부에서 즉시 state를 설정하면 React가 전체 렌더링 사이클을 다시 시작해야 합니다. Effect에서 state를 업데이트하면 React는 컴포넌트를 다시 렌더링하고, DOM에 변경 사항을 적용한 다음, Effect를 다시 실행해야 합니다. 이는 렌더링 중에 직접 데이터를 변환하거나 props에서 state를 파생시켜 피할 수 있었던 추가 렌더링 패스를 생성합니다. 대신 컴포넌트의 최상위 레벨에서 데이터를 변환하세요. 이 코드는 추가 렌더링 사이클을 트리거하지 않고 props나 state가 변경될 때 자연스럽게 다시 실행됩니다.
-Synchronous `setState` calls in effects trigger immediate re-renders before the browser can paint, causing performance issues and visual jank. React has to render twice: once to apply the state update, then again after effects run. This double rendering is wasteful when the same result could be achieved with a single render.
+Effect에서 동기적으로 `setState`를 호출하면 브라우저가 페인트하기 전에 즉시 재렌더링이 트리거되어 성능 문제와 시각적 끊김이 발생합니다. React는 두 번 렌더링해야 합니다. 한 번은 state 업데이트를 적용하고, 또 한 번은 Effect가 실행된 후입니다. 단일 렌더링으로 동일한 결과를 얻을 수 있을 때 이러한 이중 렌더링은 낭비입니다.
-In many cases, you may also not need an effect at all. Please see [You Might Not Need an Effect](/learn/you-might-not-need-an-effect) for more information.
+많은 경우 Effect가 전혀 필요하지 않을 수도 있습니다. 자세한 내용은 [Effect가 필요하지 않은 경우](/learn/you-might-not-need-an-effect)를 참고하세요.
-## Common Violations {/*common-violations*/}
+## 일반적인 위반 사례 {/*common-violations*/}
-This rule catches several patterns where synchronous setState is used unnecessarily:
+이 규칙은 동기적으로 `setState`가 불필요하게 사용되는 여러 패턴을 감지합니다.
-- Setting loading state synchronously
-- Deriving state from props in effects
-- Transforming data in effects instead of render
+- 로딩 상태를 동기적으로 설정
+- Effect에서 props로부터 state 파생
+- 렌더링 대신 Effect에서 데이터 변환
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-Examples of incorrect code for this rule:
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
-// ❌ Synchronous setState in effect
+// ❌ Effect에서 동기적으로 setState
function Component({data}) {
const [items, setItems] = useState([]);
useEffect(() => {
- setItems(data); // Extra render, use initial state instead
+ setItems(data); // 추가 렌더링, 대신 초기 상태를 사용하세요
}, [data]);
}
-// ❌ Setting loading state synchronously
+// ❌ 로딩 상태를 동기적으로 설정
function Component() {
const [loading, setLoading] = useState(false);
useEffect(() => {
- setLoading(true); // Synchronous, causes extra render
+ setLoading(true); // 동기적, 추가 렌더링 발생
fetchData().then(() => setLoading(false));
}, []);
}
-// ❌ Transforming data in effect
+// ❌ Effect에서 데이터 변환
function Component({rawData}) {
const [processed, setProcessed] = useState([]);
useEffect(() => {
- setProcessed(rawData.map(transform)); // Should derive in render
+ setProcessed(rawData.map(transform)); // 렌더링 중에 생성해야 함
}, [rawData]);
}
-// ❌ Deriving state from props
+// ❌ props로부터 state 파생
function Component({selectedId, items}) {
const [selected, setSelected] = useState(null);
@@ -67,12 +67,12 @@ function Component({selectedId, items}) {
}
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
-// ✅ setState in an effect is fine if the value comes from a ref
+// ✅ 값이 ref에서 오는 경우 Effect에서 setState는 괜찮습니다
function Tooltip() {
const ref = useRef(null);
const [tooltipHeight, setTooltipHeight] = useState(0);
@@ -83,11 +83,11 @@ function Tooltip() {
}, []);
}
-// ✅ Calculate during render
+// ✅ 렌더링 중에 계산
function Component({selectedId, items}) {
const selected = items.find(i => i.id === selectedId);
return {selected?.name}
;
}
```
-**When something can be calculated from the existing props or state, don't put it in state.** Instead, calculate it during rendering. This makes your code faster, simpler, and less error-prone. Learn more in [You Might Not Need an Effect](/learn/you-might-not-need-an-effect).
+**기존 props나 state로부터 계산할 수 있는 경우 state에 넣지 마세요.** 대신 렌더링 중에 계산하세요. 이렇게 하면 코드가 더 빠르고 간단하며 오류가 덜 발생합니다. 자세한 내용은 [Effect가 필요하지 않은 경우](/learn/you-might-not-need-an-effect)를 참고하세요.
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/set-state-in-render.md b/src/content/reference/eslint-plugin-react-hooks/lints/set-state-in-render.md
index 8c8c812f0..4432da0c6 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/set-state-in-render.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/set-state-in-render.md
@@ -4,37 +4,37 @@ title: set-state-in-render
-Validates against unconditionally setting state during render, which can trigger additional renders and potential infinite render loops.
+렌더링 중에 무조건 state를 설정하는 것에 대해 검증합니다. 이는 추가 렌더링과 잠재적인 무한 렌더링 루프를 트리거할 수 있습니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 정보 {/*rule-details*/}
-Calling `setState` during render unconditionally triggers another render before the current one finishes. This creates an infinite loop that crashes your app.
+렌더링 중에 무조건 `setState`를 호출하면 현재 렌더링이 완료되기 전에 다른 렌더링이 트리거됩니다. 이는 앱을 충돌시키는 무한 루프를 생성합니다.
-## Common Violations {/*common-violations*/}
+## 일반적인 위반 사례 {/*common-violations*/}
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
```js
-// ❌ Unconditional setState directly in render
+// ❌ 렌더링 중에 직접 무조건 setState
function Component({value}) {
const [count, setCount] = useState(0);
- setCount(value); // Infinite loop!
+ setCount(value); // 무한 루프!
return {count}
;
}
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
```js
-// ✅ Derive during render
+// ✅ 렌더링 중에 파생
function Component({items}) {
- const sorted = [...items].sort(); // Just calculate it in render
+ const sorted = [...items].sort(); // 렌더링 중에 계산
return ;
}
-// ✅ Set state in event handler
+// ✅ 이벤트 핸들러에서 state 설정
function Component() {
const [count, setCount] = useState(0);
return (
@@ -44,20 +44,20 @@ function Component() {
);
}
-// ✅ Derive from props instead of setting state
+// ✅ state를 설정하는 대신 props에서 파생
function Component({user}) {
const name = user?.name || '';
const email = user?.email || '';
return {name}
;
}
-// ✅ Conditionally derive state from props and state from previous renders
+// ✅ 이전 렌더링의 props와 state로부터 조건부로 state 파생
function Component({ items }) {
const [isReverse, setIsReverse] = useState(false);
const [selection, setSelection] = useState(null);
const [prevItems, setPrevItems] = useState(items);
- if (items !== prevItems) { // This condition makes it valid
+ if (items !== prevItems) { // 이 조건이 유효하게 만듭니다
setPrevItems(items);
setSelection(null);
}
@@ -65,14 +65,14 @@ function Component({ items }) {
}
```
-## Troubleshooting {/*troubleshooting*/}
+## 문제 해결 {/*troubleshooting*/}
-### I want to sync state to a prop {/*clamp-state-to-prop*/}
+### state를 prop과 동기화하고 싶습니다 {/*clamp-state-to-prop*/}
-A common problem is trying to "fix" state after it renders. Suppose you want to keep a counter from exceeding a `max` prop:
+일반적인 문제는 렌더링 후 state를 "수정"하려고 시도하는 것입니다. 카운터가 `max` prop을 초과하지 않도록 유지하고 싶다고 가정해봅시다.
```js
-// ❌ Wrong: clamps during render
+// ❌ 잘못된 예시: 렌더링 중에 제한
function Counter({max}) {
const [count, setCount] = useState(0);
@@ -88,12 +88,12 @@ function Counter({max}) {
}
```
-As soon as `count` exceeds `max`, an infinite loop is triggered.
+`count`가 `max`를 초과하자마자 무한 루프가 트리거됩니다.
-Instead, it's often better to move this logic to the event (the place where the state is first set). For example, you can enforce the maximum at the moment you update state:
+대신 이 로직을 이벤트(state가 처음 설정되는 곳)로 이동하는 것이 더 좋습니다. 예를 들어 state를 업데이트하는 순간에 최댓값을 적용할 수 있습니다.
```js
-// ✅ Clamp when updating
+// ✅ 업데이트할 때 제한
function Counter({max}) {
const [count, setCount] = useState(0);
@@ -105,6 +105,6 @@ function Counter({max}) {
}
```
-Now the setter only runs in response to the click, React finishes the render normally, and `count` never crosses `max`.
+이제 setter는 클릭에 대한 응답으로만 실행되고, React는 정상적으로 렌더링을 완료하며, `count`는 절대 `max`를 넘지 않습니다.
-In rare cases, you may need to adjust state based on information from previous renders. For those, follow [this pattern](https://react.dev/reference/react/useState#storing-information-from-previous-renders) of setting state conditionally.
+드문 경우지만 이전 렌더링의 정보를 기반으로 state를 조정해야 할 수 있습니다. 그런 경우 조건부로 state를 설정하는 [이 패턴](/reference/react/useState#storing-information-from-previous-renders)을 따르세요.
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/static-components.md b/src/content/reference/eslint-plugin-react-hooks/lints/static-components.md
index efc2ee05e..54fb246f1 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/static-components.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/static-components.md
@@ -4,30 +4,30 @@ title: static-components
-Validates that components are static, not recreated every render. Components that are recreated dynamically can reset state and trigger excessive re-rendering.
+컴포넌트가 정적이며 렌더링할 때마다 다시 생성되지 않는지 검증합니다. 동적으로 다시 생성되는 컴포넌트는 state를 초기화하고 과도한 재렌더링을 트리거할 수 있습니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 정보 {/*rule-details*/}
-Components defined inside other components are recreated on every render. React sees each as a brand new component type, unmounting the old one and mounting the new one, destroying all state and DOM nodes in the process.
+다른 컴포넌트 내부에 정의된 컴포넌트는 렌더링할 때마다 다시 생성됩니다. React는 각각을 완전히 새로운 컴포넌트 타입으로 간주하여 이전 컴포넌트를 마운트 해제하고 새 컴포넌트를 마운트하며, 그 과정에서 모든 state와 DOM 노드를 파괴합니다.
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-Examples of incorrect code for this rule:
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
-// ❌ Component defined inside component
+// ❌ 컴포넌트 내부에 컴포넌트 정의
function Parent() {
- const ChildComponent = () => { // New component every render!
+ const ChildComponent = () => { // 렌더링할 때마다 새 컴포넌트!
const [count, setCount] = useState(0);
return setCount(count + 1)}>{count} ;
};
- return Click
@@ -37,36 +37,36 @@ function Parent({type}) {
}
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
-// ✅ Components at module level
+// ✅ 모듈 레벨의 컴포넌트
const ButtonComponent = () => Click ;
const TextComponent = () => Text
;
function Parent({type}) {
const Component = type === 'button'
- ? ButtonComponent // Reference existing component
+ ? ButtonComponent // 기존 컴포넌트 참조
: TextComponent;
return
Click me
@@ -78,10 +78,10 @@ function Parent() {
}
```
-Pass data as props instead:
+대신 데이터를 props로 전달하세요.
```js
-// ✅ Better: Pass props to static component
+// ✅ 더 나은 방법: 정적 컴포넌트에 props 전달
function ThemedButton({theme}) {
return (
@@ -98,6 +98,6 @@ function Parent() {
-If you find yourself wanting to define components inside other components to access local variables, that's a sign you should be passing props instead. This makes components more reusable and testable.
+로컬 변수에 액세스하기 위해 다른 컴포넌트 내부에 컴포넌트를 정의하고 싶다면, 대신 props를 전달해야 한다는 신호입니다. 이렇게 하면 컴포넌트를 더 재사용 가능하고 테스트하기 쉽게 만들 수 있습니다.
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/unsupported-syntax.md b/src/content/reference/eslint-plugin-react-hooks/lints/unsupported-syntax.md
index d7a751d05..2157aa1df 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/unsupported-syntax.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/unsupported-syntax.md
@@ -4,92 +4,92 @@ title: unsupported-syntax
-Validates against syntax that React Compiler does not support. If you need to, you can still use this syntax outside of React, such as in a standalone utility function.
+React 컴파일러가 지원하지 않는 문법에 대해 검증합니다. 필요한 경우 독립적인 유틸리티 함수와 같이 React 외부에서 이 문법을 계속 사용할 수 있습니다.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 정보 {/*rule-details*/}
-React Compiler needs to statically analyze your code to apply optimizations. Features like `eval` and `with` make it impossible to statically understand what the code does at compile time, so the compiler can't optimize components that use them.
+React 컴파일러는 최적화를 적용하기 위해 코드를 정적으로 분석합니다. `eval` 및 `with`와 같은 기능은 컴파일 타임에 코드가 무엇을 하는지 정적으로 이해하는 것을 불가능하게 만들기 때문에 컴파일러는 이를 사용하는 컴포넌트를 최적화할 수 없습니다.
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-Examples of incorrect code for this rule:
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
-// ❌ Using eval in component
+// ❌ 컴포넌트에서 eval 사용
function Component({ code }) {
- const result = eval(code); // Can't be analyzed
+ const result = eval(code); // 분석할 수 없음
return {result}
;
}
-// ❌ Using with statement
+// ❌ with 문 사용
function Component() {
- with (Math) { // Changes scope dynamically
+ with (Math) { // 동적으로 스코프 변경
return {sin(PI / 2)}
;
}
}
-// ❌ Dynamic property access with eval
+// ❌ eval을 사용한 동적 프로퍼티 액세스
function Component({propName}) {
const value = eval(`props.${propName}`);
return {value}
;
}
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
-// ✅ Use normal property access
+// ✅ 일반적인 프로퍼티 액세스 사용
function Component({propName, props}) {
- const value = props[propName]; // Analyzable
+ const value = props[propName]; // 분석 가능
return {value}
;
}
-// ✅ Use standard Math methods
+// ✅ 표준 Math 메서드 사용
function Component() {
return {Math.sin(Math.PI / 2)}
;
}
```
-## Troubleshooting {/*troubleshooting*/}
+## 문제 해결 {/*troubleshooting*/}
-### I need to evaluate dynamic code {/*evaluate-dynamic-code*/}
+### 동적 코드를 평가해야 합니다 {/*evaluate-dynamic-code*/}
-You might need to evaluate user-provided code:
+사용자가 제공한 코드를 평가해야 할 수 있습니다.
```js
-// ❌ Wrong: eval in component
+// ❌ 잘못된 예시: 컴포넌트에서 eval
function Calculator({expression}) {
- const result = eval(expression); // Unsafe and unoptimizable
- return Result: {result}
;
+ const result = eval(expression); // 안전하지 않고 최적화 불가능
+ return 결과: {result}
;
}
```
-Use a safe expression parser instead:
+대신 안전한 표현식 파서를 사용하세요.
```js
-// ✅ Better: Use a safe parser
-import {evaluate} from 'mathjs'; // or similar library
+// ✅ 더 나은 방법: 안전한 파서 사용
+import {evaluate} from 'mathjs'; // 또는 유사한 라이브러리
function Calculator({expression}) {
const [result, setResult] = useState(null);
const calculate = () => {
try {
- // Safe mathematical expression evaluation
+ // 안전한 수학적 표현식 평가
setResult(evaluate(expression));
} catch (error) {
- setResult('Invalid expression');
+ setResult('잘못된 표현식');
}
};
return (
-
Calculate
- {result &&
Result: {result}
}
+
계산
+ {result &&
결과: {result}
}
-Never use `eval` with user input - it's a security risk. Use dedicated parsing libraries for specific use cases like mathematical expressions, JSON parsing, or template evaluation.
+사용자 입력과 함께 `eval`을 절대 사용하지 마세요. 보안 위험이 있습니다. 수학적 표현식, JSON 파싱 또는 템플릿 평가와 같은 특정 사용 사례에는 전용 파싱 라이브러리를 사용하세요.
diff --git a/src/content/reference/eslint-plugin-react-hooks/lints/use-memo.md b/src/content/reference/eslint-plugin-react-hooks/lints/use-memo.md
index 674ffef0a..f20f91d13 100644
--- a/src/content/reference/eslint-plugin-react-hooks/lints/use-memo.md
+++ b/src/content/reference/eslint-plugin-react-hooks/lints/use-memo.md
@@ -4,36 +4,36 @@ title: use-memo
-Validates that the `useMemo` hook is used with a return value. See [`useMemo` docs](/reference/react/useMemo) for more information.
+`useMemo` Hook이 반환값과 함께 사용되는지 검증합니다. 자세한 내용은 [`useMemo` 문서](/reference/react/useMemo)를 참고하세요.
-## Rule Details {/*rule-details*/}
+## 규칙 세부 정보 {/*rule-details*/}
-`useMemo` is for computing and caching expensive values, not for side effects. Without a return value, `useMemo` returns `undefined`, which defeats its purpose and likely indicates you're using the wrong hook.
+`useMemo`는 비용이 많이 드는 값을 계산하고 캐싱하기 위한 것이지 부수 효과Side Effect 를 위한 것이 아닙니다. 반환값이 없으면 `useMemo`는 `undefined`를 반환하여 목적을 달성하지 못하며, 잘못된 Hook을 사용하고 있음을 나타낼 가능성이 높습니다.
-### Invalid {/*invalid*/}
+### 잘못된 예시 {/*invalid*/}
-Examples of incorrect code for this rule:
+이 규칙에 대한 잘못된 코드 예시입니다.
```js
-// ❌ No return value
+// ❌ 반환값 없음
function Component({ data }) {
const processed = useMemo(() => {
data.forEach(item => console.log(item));
- // Missing return!
+ // return 누락!
}, [data]);
- return {processed}
; // Always undefined
+ return {processed}
; // 항상 undefined
}
```
-### Valid {/*valid*/}
+### 올바른 예시 {/*valid*/}
-Examples of correct code for this rule:
+이 규칙에 대한 올바른 코드 예시입니다.
```js
-// ✅ Returns computed value
+// ✅ 계산된 값 반환
function Component({ data }) {
const processed = useMemo(() => {
return data.map(item => item * 2);
@@ -43,52 +43,52 @@ function Component({ data }) {
}
```
-## Troubleshooting {/*troubleshooting*/}
+## 문제 해결 {/*troubleshooting*/}
-### I need to run side effects when dependencies change {/*side-effects*/}
+### 의존성이 변경될 때 부수 효과를 실행해야 합니다 {/*side-effects*/}
-You might try to use `useMemo` for side effects:
+부수 효과Side Effect 에 `useMemo`를 사용하려고 할 수 있습니다.
{/* TODO(@poteto) fix compiler validation to check for unassigned useMemos */}
```js
-// ❌ Wrong: Side effects in useMemo
+// ❌ 잘못된 예시: useMemo에서 부수 효과
function Component({user}) {
- // No return value, just side effect
+ // 반환값 없음, 부수 효과만
useMemo(() => {
analytics.track('UserViewed', {userId: user.id});
}, [user.id]);
- // Not assigned to a variable
+ // 변수에 할당되지 않음
useMemo(() => {
return analytics.track('UserViewed', {userId: user.id});
}, [user.id]);
}
```
-If the side effect needs to happen in response to user interaction, it's best to colocate the side effect with the event:
+부수 효과가 사용자 상호작용에 대한 응답으로 발생해야 하는 경우 부수 효과를 이벤트와 함께 배치하는 것이 가장 좋습니다.
```js
-// ✅ Good: Side effects in event handlers
+// ✅ 좋은 예시: 이벤트 핸들러에서 부수 효과
function Component({user}) {
const handleClick = () => {
analytics.track('ButtonClicked', {userId: user.id});
- // Other click logic...
+ // 기타 클릭 로직...
};
return Click me ;
}
```
-If the side effect sychronizes React state with some external state (or vice versa), use `useEffect`:
+부수 효과가 React state를 외부 state와 동기화하는 경우(또는 그 반대) `useEffect`를 사용하세요.
```js
-// ✅ Good: Synchronization in useEffect
+// ✅ 좋은 예시: useEffect에서 동기화
function Component({theme}) {
useEffect(() => {
localStorage.setItem('preferredTheme', theme);
document.body.className = theme;
}, [theme]);
- return Current theme: {theme}
;
+ return 현재 테마: {theme}
;
}
```
diff --git a/src/content/reference/react/index.md b/src/content/reference/react/index.md
index b1d0e86c7..12ba85950 100644
--- a/src/content/reference/react/index.md
+++ b/src/content/reference/react/index.md
@@ -41,7 +41,7 @@ The React Compiler is a build-time optimization tool that automatically memoizes
The [ESLint plugin for React Hooks](/reference/eslint-plugin-react-hooks) helps enforce the Rules of React:
-* [Lints](/reference/eslint-plugin-react-hooks) - Detailed documentation for each lint with examples.
+* [린트](/reference/eslint-plugin-react-hooks) - Detailed documentation for each lint with examples.
## Rules of React {/*rules-of-react*/}
diff --git a/src/sidebarReference.json b/src/sidebarReference.json
index 1d623df86..ee59f6724 100644
--- a/src/sidebarReference.json
+++ b/src/sidebarReference.json
@@ -409,7 +409,7 @@
"sectionHeader": "eslint-plugin-react-hooks"
},
{
- "title": "Lints",
+ "title": "린트",
"path": "/reference/eslint-plugin-react-hooks",
"routes": [
{