Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translate Composition vs Inheritance #22

Merged
merged 5 commits into from
Feb 28, 2019
Merged
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 22 additions & 22 deletions content/docs/composition-vs-inheritance.md
Original file line number Diff line number Diff line change
@@ -1,22 +1,22 @@
---
id: composition-vs-inheritance
title: Composition vs Inheritance
title: 합성 (Composition) vs 상속 (Inheritance)
permalink: docs/composition-vs-inheritance.html
redirect_from:
- "docs/multiple-components.html"
prev: lifting-state-up.html
next: thinking-in-react.html
---

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

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.
이번 문서에서는 React를 처음 접한 개발자들이 종종 상속으로 인해 부딪히는 몇 가지 문제들과 합성을 통해 이러한 문제를 해결하는 방법을 살펴볼 것입니다.

## Containment {#containment}
## 컴포넌트에서 다른 컴포넌트를 담기 {#containment}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

containment는 (좋지 않은 일의) 방지[억제], (다른 국가의 무력에 대한) 견제, 격납 등으로 해석하는데, 격납이라고만 해석하기엔 의미가 전달되는 것 같지 않아 내용을 조금 풀어서 컴포넌트에서 다른 컴포넌트를 담기라고 번역했습니다.


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

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

```js{4}
function FancyBorder(props) {
Expand All @@ -28,7 +28,7 @@ function FancyBorder(props) {
}
```

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

```js{4-9}
function WelcomeDialog() {
Expand All @@ -45,11 +45,11 @@ function WelcomeDialog() {
}
```

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

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.
`<FancyBorder>` JSX 태그 안에 있는 것들이 `FancyBorder` 컴포넌트의 `children` prop으로 전달됩니다. `FancyBorder``{props.children}``<div>` 안에 렌더링하므로 전달된 엘리먼트들이 최종 출력됩니다.

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`:
흔하진 않지만 종종 컴포넌트에 여러 개의 "구멍"이 필요할 수도 있습니다. 이런 경우에는 `children` 대신 자신만의 고유한 방식을 적용할 수도 있습니다.

```js{5,8,18,21}
function SplitPane(props) {
Expand Down Expand Up @@ -78,15 +78,15 @@ function App() {
}
```

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

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.
`<Contacts />``<Chat />`같은 React 엘리먼트는 단지 객체이기 때문에 다른 데이터처럼 prop으로 전달할 수 있습니다. 이러한 접근은 다른 라이브러리의 "슬롯 (slots)"과 비슷해보이지만 React에서 prop으로 전달할 수 있는 것에는 제한이 없습니다.

## Specialization {#specialization}
## 특수화 {#specialization}

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`.
때로는 어떤 컴포넌트의 "특수한 경우"인 컴포넌트를 고려해야 하는 경우가 있습니다. 예를 들어, `WelcomeDialog`는 `Dialog`의 특수한 경우라고 할 수 있습니다.

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

```js{5,8,16-18}
function Dialog(props) {
Expand All @@ -111,9 +111,9 @@ function WelcomeDialog() {
}
```

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

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

```js{10,27-31}
function Dialog(props) {
Expand Down Expand Up @@ -161,12 +161,12 @@ class SignUpDialog extends React.Component {
}
```

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

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

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.
Facebook에서는 수천 개의 React 컴포넌트를 사용하지만, 컴포넌트를 상속 계층 구조로 작성을 권장할만한 사례를 아직 찾지 못했습니다.

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.
props와 합성은 명시적이고 안전한 방법으로 컴포넌트의 모양과 동작을 커스터마이징하는데 필요한 모든 유연성을 제공합니다. 컴포넌트가 원시 타입의 값, React 엘리먼트 혹은 함수 등 어떠한 props도 받을 수 있다는 것을 기억하세요.

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.
UI가 아닌 기능을 여러 컴포넌트에서 재사용하기를 원한다면, 별도의 JavaScript 모듈로 분리하는 것이 좋습니다. 컴포넌트에서 해당 함수, 객체, 클래스 등을 import 하여 사용할 수 있습니다. 상속받을 필요 없이 말이죠.