Skip to content

Commit 3762413

Browse files
authored
Merge pull request #22 from hewonjeong/composition-vs-inheritance
Translate Composition vs Inheritance
2 parents db531a8 + 0769121 commit 3762413

File tree

1 file changed

+22
-22
lines changed

1 file changed

+22
-22
lines changed

Diff for: content/docs/composition-vs-inheritance.md

+22-22
Original file line numberDiff line numberDiff line change
@@ -1,22 +1,22 @@
11
---
22
id: composition-vs-inheritance
3-
title: Composition vs Inheritance
3+
title: 합성 (Composition) vs 상속 (Inheritance)
44
permalink: docs/composition-vs-inheritance.html
55
redirect_from:
66
- "docs/multiple-components.html"
77
prev: lifting-state-up.html
88
next: thinking-in-react.html
99
---
1010

11-
React has a powerful composition model, and we recommend using composition instead of inheritance to reuse code between components.
11+
React는 강력한 합성 모델을 가지고 있으며, 상속 대신 합성을 사용하여 컴포넌트 간에 코드를 재사용하는 것이 좋습니다.
1212

13-
In this section, we will consider a few problems where developers new to React often reach for inheritance, and show how we can solve them with composition.
13+
이번 문서에서는 React를 처음 접한 개발자들이 종종 상속으로 인해 부딪히는 몇 가지 문제들과 합성을 통해 이러한 문제를 해결하는 방법을 살펴볼 것입니다.
1414

15-
## Containment {#containment}
15+
## 컴포넌트에서 다른 컴포넌트를 담기 {#containment}
1616

17-
Some components don't know their children ahead of time. This is especially common for components like `Sidebar` or `Dialog` that represent generic "boxes".
17+
어떤 컴포넌트들은 어떤 자식 엘리먼트가 들어올 지 미리 예상할 수 없는 경우가 있습니다. 범용적인 '박스' 역할을 하는 `Sidebar` 혹은 `Dialog`와 같은 컴포넌트에서 특히 자주 볼 수 있습니다.
1818

19-
We recommend that such components use the special `children` prop to pass children elements directly into their output:
19+
이러한 컴포넌트에서는 특수한 `children` prop을 사용하여 자식 엘리먼트를 출력에 그대로 전달하는 것이 좋습니다.
2020

2121
```js{4}
2222
function FancyBorder(props) {
@@ -28,7 +28,7 @@ function FancyBorder(props) {
2828
}
2929
```
3030

31-
This lets other components pass arbitrary children to them by nesting the JSX:
31+
이러한 방식으로 다른 컴포넌트에서 JSX를 중첩하여 임의의 자식을 전달할 수 있습니다.
3232

3333
```js{4-9}
3434
function WelcomeDialog() {
@@ -45,11 +45,11 @@ function WelcomeDialog() {
4545
}
4646
```
4747

48-
**[Try it on CodePen](https://codepen.io/gaearon/pen/ozqNOV?editors=0010)**
48+
**[CodePen에서 실행하기](https://codepen.io/gaearon/pen/ozqNOV?editors=0010)**
4949

50-
Anything inside the `<FancyBorder>` JSX tag gets passed into the `FancyBorder` component as a `children` prop. Since `FancyBorder` renders `{props.children}` inside a `<div>`, the passed elements appear in the final output.
50+
`<FancyBorder>` JSX 태그 안에 있는 것들이 `FancyBorder` 컴포넌트의 `children` prop으로 전달됩니다. `FancyBorder``{props.children}``<div>` 안에 렌더링하므로 전달된 엘리먼트들이 최종 출력됩니다.
5151

52-
While this is less common, sometimes you might need multiple "holes" in a component. In such cases you may come up with your own convention instead of using `children`:
52+
흔하진 않지만 종종 컴포넌트에 여러 개의 "구멍"이 필요할 수도 있습니다. 이런 경우에는 `children` 대신 자신만의 고유한 방식을 적용할 수도 있습니다.
5353

5454
```js{5,8,18,21}
5555
function SplitPane(props) {
@@ -78,15 +78,15 @@ function App() {
7878
}
7979
```
8080

81-
[**Try it on CodePen**](https://codepen.io/gaearon/pen/gwZOJp?editors=0010)
81+
[**CodePen에서 실행하기**](https://codepen.io/gaearon/pen/gwZOJp?editors=0010)
8282

83-
React elements like `<Contacts />` and `<Chat />` are just objects, so you can pass them as props like any other data. This approach may remind you of "slots" in other libraries but there are no limitations on what you can pass as props in React.
83+
`<Contacts />``<Chat />`같은 React 엘리먼트는 단지 객체이기 때문에 다른 데이터처럼 prop으로 전달할 수 있습니다. 이러한 접근은 다른 라이브러리의 "슬롯 (slots)"과 비슷해보이지만 React에서 prop으로 전달할 수 있는 것에는 제한이 없습니다.
8484

85-
## Specialization {#specialization}
85+
## 특수화 {#specialization}
8686

87-
Sometimes we think about components as being "special cases" of other components. For example, we might say that a `WelcomeDialog` is a special case of `Dialog`.
87+
때로는 어떤 컴포넌트의 "특수한 경우"인 컴포넌트를 고려해야 하는 경우가 있습니다. 예를 들어, `WelcomeDialog``Dialog`의 특수한 경우라고 할 수 있습니다.
8888

89-
In React, this is also achieved by composition, where a more "specific" component renders a more "generic" one and configures it with props:
89+
React에서는 이 역시 합성을 통해 해결할 수 있습니다. 더 "구체적인" 컴포넌트가 "일반적인" 컴포넌트를 렌더링하고 props를 통해 내용을 구성합니다.
9090

9191
```js{5,8,16-18}
9292
function Dialog(props) {
@@ -111,9 +111,9 @@ function WelcomeDialog() {
111111
}
112112
```
113113

114-
[**Try it on CodePen**](https://codepen.io/gaearon/pen/kkEaOZ?editors=0010)
114+
[**CodePen에서 실행하기**](https://codepen.io/gaearon/pen/kkEaOZ?editors=0010)
115115

116-
Composition works equally well for components defined as classes:
116+
합성은 클래스로 정의된 컴포넌트에서도 동일하게 적용됩니다.
117117

118118
```js{10,27-31}
119119
function Dialog(props) {
@@ -161,12 +161,12 @@ class SignUpDialog extends React.Component {
161161
}
162162
```
163163

164-
[**Try it on CodePen**](https://codepen.io/gaearon/pen/gwZbYa?editors=0010)
164+
[**CodePen에서 실행하기**](https://codepen.io/gaearon/pen/gwZbYa?editors=0010)
165165

166-
## So What About Inheritance? {#so-what-about-inheritance}
166+
## 그렇다면 상속은? {#so-what-about-inheritance}
167167

168-
At Facebook, we use React in thousands of components, and we haven't found any use cases where we would recommend creating component inheritance hierarchies.
168+
Facebook에서는 수천 개의 React 컴포넌트를 사용하지만, 컴포넌트를 상속 계층 구조로 작성을 권장할만한 사례를 아직 찾지 못했습니다.
169169

170-
Props and composition give you all the flexibility you need to customize a component's look and behavior in an explicit and safe way. Remember that components may accept arbitrary props, including primitive values, React elements, or functions.
170+
props와 합성은 명시적이고 안전한 방법으로 컴포넌트의 모양과 동작을 커스터마이징하는데 필요한 모든 유연성을 제공합니다. 컴포넌트가 원시 타입의 값, React 엘리먼트 혹은 함수 등 어떠한 props도 받을 수 있다는 것을 기억하세요.
171171

172-
If you want to reuse non-UI functionality between components, we suggest extracting it into a separate JavaScript module. The components may import it and use that function, object, or a class, without extending it.
172+
UI가 아닌 기능을 여러 컴포넌트에서 재사용하기를 원한다면, 별도의 JavaScript 모듈로 분리하는 것이 좋습니다. 컴포넌트에서 해당 함수, 객체, 클래스 등을 import 하여 사용할 수 있습니다. 상속받을 필요 없이 말이죠.

0 commit comments

Comments
 (0)