Skip to content
This repository has been archived by the owner on Jan 5, 2025. It is now read-only.

merge pull requests #273

Merged
merged 14 commits into from
Mar 14, 2024
Merged
3 changes: 1 addition & 2 deletions src/components/MDX/TeamMember.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,6 @@ interface TeamMemberProps {
// TODO: good alt text for images/links
export function TeamMember({
name,
id,
title,
children,
photo,
Expand Down Expand Up @@ -58,7 +57,7 @@ export function TeamMember({
<Image src={photo} layout="fill" objectFit="cover" alt={name} />
</div>
<div className="ps-0 sm:ps-6 basis-3/5 items-start">
<H3 className="mb-1 sm:my-0" id={id}>
<H3 className="mb-1 sm:my-0" id={name}>
{name}
</H3>
{title && <div>{title}</div>}
Expand Down
13 changes: 11 additions & 2 deletions src/content/learn/describing-the-ui.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: Describing the UI
translatedTitle: UI 구성하기
translators: [박문하, 안예지, 정재남, 이나령]
translators: [박문하, 안예지, 정재남, 이나령, 윤다솜]
---

<Intro>
Expand Down Expand Up @@ -31,6 +31,7 @@ React is a JavaScript library for rendering user interfaces (UI). UI is built fr
- [컴포넌트를 조건부로 렌더링하는 방법](/learn/conditional-rendering)
- [한 번에 여러 컴포넌트를 렌더링하는 방법](/learn/rendering-lists)
- [컴포넌트를 순수하게 유지하여 혼란스러운 버그를 피하는 방법](/learn/keeping-components-pure)
- [UI를 트리로 이해하는것이 유용한 이유](/learn/understanding-your-ui-as-a-tree)
</TransBlock>
</YouWillLearn>

Expand Down Expand Up @@ -545,33 +546,41 @@ Read **[Keeping Components Pure](/learn/keeping-components-pure)** to learn how
<Trans>컴포넌트를 순수하고 예측 가능한 함수로 작성하는 방법을 알아보려면 [**컴포넌트 순수성 유지**](/learn/keeping-components-pure)를 읽어보세요.</Trans>
</LearnMore>

## Your UI as a tree {/*your-ui-as-a-tree*/}
## Your UI as a tree<Trans>트리로서의 UI</Trans> {/*your-ui-as-a-tree*/}

React uses trees to model the relationships between components and modules.
<Trans>React는 모듈과 컴포넌트 사이의 관계를 트리 형태로 구성합니다.</Trans>

A React render tree is a representation of the parent and child relationship between components.
<Trans>React의 렌더 트리는 컴포넌트간의 부모와 자식관계를 나타낼 수 있습니다.</Trans>

<Diagram name="generic_render_tree" height={250} width={500} alt="A tree graph with five nodes, with each node representing a component. The root node is located at the top the tree graph and is labelled 'Root Component'. It has two arrows extending down to two nodes labelled 'Component A' and 'Component C'. Each of the arrows is labelled with 'renders'. 'Component A' has a single 'renders' arrow to a node labelled 'Component B'. 'Component C' has a single 'renders' arrow to a node labelled 'Component D'.">

An example React render tree.
<Trans>React 렌더 트리의 예시</Trans>

</Diagram>

Components near the top of the tree, near the root component, are considered top-level components. Components with no child components are leaf components. This categorization of components is useful for understanding data flow and rendering performance.
<Trans>트리 상단 근처, 루트 컴포넌트 근처에 있는 컴포넌트는 최상위 컴포넌트로 간주됩니다. 하위 컴포넌트가 없는 컴포넌트는 리프 컴포넌트입니다. 이러한 컴포넌트 분류는 데이터 흐름 및 렌더링 성능을 이해하는 데 유용합니다.</Trans>

Modelling the relationship between JavaScript modules is another useful way to understand your app. We refer to it as a module dependency tree.
<Trans>자바스크립트 모듈 간의 관계를 모델링하는 것은 앱을 이해하는 또 다른 유용한 방법입니다. 이를 모듈 종속성 트리라고 합니다. </Trans>

<Diagram name="generic_dependency_tree" height={250} width={500} alt="A tree graph with five nodes. Each node represents a JavaScript module. The top-most node is labelled 'RootModule.js'. It has three arrows extending to the nodes: 'ModuleA.js', 'ModuleB.js', and 'ModuleC.js'. Each arrow is labelled as 'imports'. 'ModuleC.js' node has a single 'imports' arrow that points to a node labelled 'ModuleD.js'.">

An example module dependency tree.
<Trans>모듈 의존성 트리의 예시</Trans>

</Diagram>

A dependency tree is often used by build tools to bundle all the relevant JavaScript code for the client to download and render. A large bundle size regresses user experience for React apps. Understanding the module dependency tree is helpful to debug such issues.
<Trans>종속성 트리는 클라이언트가 다운로드하고 렌더링할 모든 관련 JavaScript 코드를 묶기 위해 빌드 도구에서 자주 사용됩니다. 번들 크기가 크면 React 앱의 사용자 경험이 저하됩니다. 모듈 종속성 트리를 이해하면 이러한 문제를 디버깅하는 데 도움이 됩니다.</Trans>

<LearnMore path="/learn/understanding-your-ui-as-a-tree">

Read **[Your UI as a Tree](/learn/understanding-your-ui-as-a-tree)** to learn how to create a render and module dependency trees for a React app and how they're useful mental models for improving user experience and performance.
<Trans>React 앱을 위한 렌더 트리 및 모듈 종속성 트리를 만드는 방법과 이것이 사용자 경험과 성능을 향상시키는 데 유용한 멘탈 모델인지 알아보려면 [트리로서의 UI](/learn/understanding-your-ui-as-a-tree)를 읽어보세요.</Trans>

</LearnMore>

Expand Down
2 changes: 1 addition & 1 deletion src/content/learn/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -228,7 +228,7 @@ The markup syntax you've seen above is called *JSX*. It is optional, but most Re
<Trans>위에서 본 마크업 구문을 *JSX*라고 합니다. 선택 사항이지만 대부분의 React 프로젝트는 편의성을 위해 JSX를 사용합니다. [로컬 개발을 위해 권장하는 모든 도구](/learn/installation)는 JSX를 기본적으로 지원합니다.</Trans>

JSX is stricter than HTML. You have to close tags like `<br />`. Your component also can't return multiple JSX tags. You have to wrap them into a shared parent, like a `<div>...</div>` or an empty `<>...</>` wrapper:
<Trans>JSX는 HTML보다 더 엄격합니다. `<br />`과 같은 태그를 닫아야 합니다. 또한 컴포넌트는 여러 개의 JSX 태그를 반환할 수 없습니다. `<div>...</div>` 또는 빈 `<>...</>` 래퍼와 같이 하나의 공유 부모로 감싸야 합니다:</Trans>
<Trans>JSX는 HTML보다 더 엄격합니다. `<br />`과 같은 모습으로 태그를 닫아야 합니다. 또한 컴포넌트는 여러 개의 JSX 태그를 반환할 수 없습니다. `<div>...</div>` 또는 빈 `<>...</>` 래퍼와 같이 하나의 공유 부모로 감싸야 합니다:</Trans>

```js {3,6}
function AboutPage() {
Expand Down
1 change: 0 additions & 1 deletion src/content/learn/preserving-and-resetting-state.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,6 @@ State is isolated between components. React keeps track of which state belongs t
* How keys and types affect whether the state is preserved

<TransBlock>
- React가 컴포넌트 구조를 "보는" 방법
- React가 state를 유지하거나 재설정하도록 선택할 때
- React가 컴포넌트의 state를 재설정하도록 강제하는 방법
- key와 type이 state 보존 여부에 영향을 미치는 방법
Expand Down
2 changes: 1 addition & 1 deletion src/content/learn/separating-events-from-effects.md
Original file line number Diff line number Diff line change
Expand Up @@ -804,7 +804,7 @@ After `useEffectEvent` becomes a stable part of React, we recommend **never supp
<Trans>`useEffectEvent`가 React의 안정적인 API가 된 후에는 **Linter를 억제하지 않는 것이 좋습니다**.</Trans>

The first downside of suppressing the rule is that React will no longer warn you when your Effect needs to "react" to a new reactive dependency you've introduced to your code. In the earlier example, you added `url` to the dependencies *because* React reminded you to do it. You will no longer get such reminders for any future edits to that Effect if you disable the linter. This leads to bugs.
<Trans>이 규칙을 억제하는 첫 번째 단점은 코드에 도입한 새로운 반응형 의존성에 Efect가 "반응"해야 할 때 React가 더 이상 경고하지 않는다는 것입니다. 앞선 예제에서는 React가 알려줬기 *때문에* `url`을 의존성에 추가했습니다. Linter를 비활성화하면 해당 Effect를 이후에 수정할 때 더이상 이러한 경고를 받지 않게 됩니다. 이것은 버그로 이어질 수 있습니다.</Trans>
<Trans>이 규칙을 억제하는 첫 번째 단점은 코드에 도입한 새로운 반응형 의존성에 Effect가 "반응"해야 할 때 React가 더 이상 경고하지 않는다는 것입니다. 앞선 예제에서는 React가 알려줬기 *때문에* `url`을 의존성에 추가했습니다. Linter를 비활성화하면 해당 Effect를 이후에 수정할 때 더이상 이러한 경고를 받지 않게 됩니다. 이것은 버그로 이어질 수 있습니다.</Trans>

Here is an example of a confusing bug caused by suppressing the linter. In this example, the `handleMove` function is supposed to read the current `canMove` state variable value in order to decide whether the dot should follow the cursor. However, `canMove` is always `true` inside `handleMove`.
<Trans> 다음은 Linter를 억제하여 발생하는 혼란스러운 버그의 예입니다. 이 예제에서 `handleMove` 함수는 커서를 따라갈지 여부를 결정하기 위해 현재 `canMove` state 변수 값을 읽어야 합니다. 그러나 `canMove`는 `handleMove` 내부에서 항상 `true`입니다.</Trans>
Expand Down
Loading
Loading