React can change how you think about the designs you look at and the apps you build.
When you build a user interface with React, you will first break it apart into pieces called components.
인터페이스(Interface)
- 프로그래밍의 전반적 개념 (TS에도 등장)
- 예) 가위바위보: 반드시 2명 이상이 필요, 누가 가위 또는 바위 또는 보를 냈는지에 따라 승부가 갈림
- 예) 신호등: 도로에서 차와 보행자를 위해 필요, 초록 불이면 건널 수 있고 노란 불이면 기다려야 하고 빨간 불이면 건널 수 없음
- 환경과 내부 구성 요소들이 상호작용하기 위한, 동작에 필요한 '규칙', '약속'
Then, you will describe the different visual states for each of your components.
Finally, you will connect your components together so that the data flows through them.
In this tutorial, we’ll guide you through the thought process of building a searchable product data table with React.
JSON 데이터:
과일/채소 배열 (카테고리, 가격, 재고 여부, 이름 포함)
[
{ category: "Fruits", price: "$1", stocked: true, name: "Apple" },
{ category: "Fruits", price: "$1", stocked: true, name: "Dragonfruit" },
{ category: "Fruits", price: "$2", stocked: false, name: "Passionfruit" },
{ category: "Vegetables", price: "$2", stocked: true, name: "Spinach" },
{ category: "Vegetables", price: "$4", stocked: false, name: "Pumpkin" },
{ category: "Vegetables", price: "$1", stocked: true, name: "Peas" }
]
디자이너가 준 UI 목업:
To implement a UI in React, you will usually follow the same five steps.
Start by drawing boxes around every component and subcomponent in the mockup and naming them.
If you work with a designer, they may have already named these components in their design tool. Ask them!
Depending on your background, you can think about splitting up a design into components in different ways:
Programming — use the same techniques for deciding if you should create a new function or object.
- Programming — 새 함수나 객체 단위를 만들 때 일관된 기술 쓰기
One such technique is the single responsibility principle, that is, a component should ideally only do one thing.
- 이 기술 중 하나인 SRP(단일 책임 원칙): 컴포넌트는 이상적으로 오직 하나의 일만 해야 한다
If it ends up growing, it should be decomposed into smaller subcomponents.
(이 원칙에 따르면) 나중에 컴포넌트가 커지게 된다면, 결국 작은 서브 컴포넌트로 나눠져야 할 것이다.
CSS — consider what you would make class selectors for. (However, components are a bit less granular.)
- CSS — 어디에 클래스 선택자를 붙일 수 있을지 생각해보기 (컴포넌트들은 다소 '알갱이적'(granular)이지 못한 면이 있다 -- 작은 단위로 나누기 쉽지 않다는 뜻)
Design — consider how you would organize the design’s layers.
- Design — 디자이너의 레이어(UI)를 어떻게 조합할 수 있을지 생각해보자.
If your JSON is well-structured, you’ll often find that it naturally maps to the component structure of your UI.
That’s because UI and data models often have the same information architecture—that is, the same shape.
Separate your UI into components, where each component matches one piece of your data model.
(위 내용을 바탕으로) 목업 화면을 5가지 컴포넌트로 나누면 다음과 같다.
FilterableProductTable
(가장 바깥쪽 회색 박스)SearchBar
(상단 파란색 박스)ProductTable
(하단 보라색 박스)ProductCategoryRow
(헤더를 가리키는 초록색 박스)ProductRow
(각 행을 가리키는 노란색 박스)If you look at ProductTable
(lavender), you’ll see that the table header (containing the “Name” and “Price” labels) isn’t its own component.
ProductTable
(보라색 박스)를 보면, 제목인 헤더 부분('Name', 'Price')이 따로 박스로 나뉘어져 있지 않다.This is a matter of preference, and you could go either way.
For this example, it is a part of ProductTable
because it appears inside the ProductTable’s list.
ProductTable
리스트 내부에 나타나므로 ProductTable
의 일부라고 볼 수 있다.However, if this header grows to be complex (e.g., if you add sorting), you can move it into its own ProductTableHeader
component.
ProductTableHeader
와 같은 컴포넌트로 분리할 수 있을 것이다.Now that you’ve identified the components in the mockup, arrange them into a hierarchy.
Components that appear within another component in the mockup should appear as a child in the hierarchy:
들여쓰기가 더 바깥에 있을수록 부모 컴포넌트
내부(아래)로 내려가면서, 각각 두 개씩 서로 형제 관계인 자식 컴포넌트들이 등장
Now that you have your component hierarchy, it’s time to implement your app.
The most straightforward approach is to build a version that renders the UI from your data model without adding any interactivity… yet!
It’s often easier to build the static version first and add interactivity later.
Building a static version requires a lot of typing and no thinking, but adding interactivity requires a lot of thinking and not a lot of typing.
To build a static version of your app that renders your data model, you’ll want to build components that reuse other components and pass data using props.
Props are a way of passing data from parent to child.
State is reserved only for interactivity, that is, data that changes over time. Since this is a static version of the app, you don’t need it.
- 상태는 시간이 지나면서 변화하는 상호 작용성(interactivity)을 위해서 필요하다. 지금 만들려는 앱은 아직은 정적 버전이므로 상태가 필요 없다.
You can either build “top down” by starting with building the components higher up in the hierarchy (like FilterableProductTable
) or “bottom up” by working from components lower down (like ProductRow
).
FilterableProductTable
) 시작하는 "top down" 방식을 쓸 수도 있고, 밑에서부터(예: ProductRow
) 시작하는 "bottom up" 방식을 쓸 수도 있다.In simpler examples, it’s usually easier to go top-down, and on larger projects, it’s easier to go bottom-up.
(우리는 큰 프로젝트라 가정하고 bottom-up으로 만들어보기로 한다)
ProductCategoryRow
(초록색 박스)와 ProductRow
(노란색 박스) 컴포넌트를 만든다.function ProductCategoryRow({ category }) {
return (
<tr>
<th colSpan="2">
{category}
</th>
</tr>
);
}
function ProductRow({ product }) {
const name = product.stocked ? product.name :
<span style={{ color: 'red' }}>
{product.name}
</span>;
return (
<tr>
<td>{name}</td>
<td>{product.price}</td>
</tr>
);
}
ProductTable
(보라색 박스)을 만든다.function ProductTable({ products }) {
const rows = [];
let lastCategory = null;
products.forEach((product) => {
if (product.category !== lastCategory) {
rows.push(
<ProductCategoryRow
category={product.category}
key={product.category} />
);
}
rows.push(
<ProductRow
product={product}
key={product.name} />
);
lastCategory = product.category;
});
return (
<table>
<thead>
<tr>
<th>Name</th>
<th>Price</th>
</tr>
</thead>
<tbody>{rows}</tbody>
</table>
);
}
SearchBar
(파란색 박스)를 구현한다.function SearchBar() {
return (
<form>
<input type="text" placeholder="Search..." />
<label>
<input type="checkbox" />
{' '}
Only show products in stock
</label>
</form>
);
}
ProductTable
와 SearchBar
를 합쳐 FilterableProductTable
(가장 바깥쪽 회색 박스)을 만든다.function FilterableProductTable({ products }) {
return (
<div>
<SearchBar />
<ProductTable products={products} />
</div>
);
}
PRODUCTS
)를 props로 내려보낸다.export default function App() {
return <FilterableProductTable products={PRODUCTS} />;
}
After building your components, you’ll have a library of reusable components that render your data model.
Because this is a static app, the components will only return JSX.
The component at the top of the hierarchy (FilterableProductTable
) will take your data model as a prop.
FilterableProductTable
)가 props로 데이터 모델을 보유한다.This is called one-way data flow because the data flows down from the top-level component to the ones at the bottom of the tree.
지금까지는 상태(state)를 전혀 쓰지 않은 정적인 앱이었다. 다음 단계부터 상태를 사용할 것이다.
To make the UI interactive, you need to let users change your underlying data model. You will use state for this.
Think of state as the minimal set of changing data that your app needs to remember.
The most important principle for structuring state is to keep it DRY (Don’t Repeat Yourself).
Figure out the absolute minimal representation of the state your application needs and compute everything else on-demand.
For example, if you’re building a shopping list, you can store the items as an array in state.
If you want to also display the number of items in the list, don’t store the number of items as another state value—instead, read the length of your array.
Now think of all of the pieces of data in this example application:
- The original list of products (상품 목록 원본)
- The search text the user has entered (유저가 입력한 검색어)
- The value of the checkbox (체크박스 값)
- The filtered list of products (필터된 상품 목록)
Which of these are state? Identify the ones that are not:
상태가 아닌 것을 정의해보자.
- Does it remain unchanged over time? (시간이 지나도 변하지 않는가?)
- Is it passed in from a parent via props? (부모 컴포넌트에서 props로 전달되었는가?)
- Can you compute it based on existing state or props in your component? (기존의 state나 props를 가지고 연산 가능한가?)
위 세 가지에 해당한다면 상태가 아니다.
Let’s go through them one by one again:
- The original list of products is passed in as props, so it’s not state.
- 상품 목록 원본(= JSON 데이터)
- 부모에서 props로 전달됨 - 상태 아님
- The search text seems to be state since it changes over time and can’t be computed from anything.
- 입력된 검색어
- 시간이 지남에 따라 변화 가능
- 다른 요소로부터 연산 불가 - 상태
- The value of the checkbox seems to be state since it changes over time and can’t be computed from anything.
- 체크박스의 체크 값
- 시간이 지남에 따라 변화 가능
- 다른 요소로부터 연산 불가 - 상태
- The filtered list of products isn’t state because it can be computed by taking the original list of products and filtering it according to the search text and value of the checkbox.
- 필터링된 상품 목록
- 기존 값(상품 목록 원본)을 통해 연산 가능 (=> 검색과 체크박스 체크로 필터링됨) - 상태 아님
This means only the search text and the value of the checkbox are state!
After identifying your app’s minimal state data, you need to identify which component is responsible for changing this state, or owns the state.
Remember: React uses one-way data flow, passing data down the component hierarchy from parent to child component.
You can figure it out by following these steps!
- Identify every component that renders something based on that state.
- 상태를 기반으로 뭔가를 렌더링하는 모든 컴포넌트를 확인하자.
- Find their closest common parent component—a component above them all in the hierarchy.
- 가장 가까운 공통된 부모 컴포넌트(위계 구조에서 해당 컴포넌트의 위에 있는 컴포넌트)를 찾자.
상태가 어디에 있어야 할지 결정하기:
1) Often, you can put the state directly into their common parent.
2) You can also put the state into some component above their common parent.
3) If you can’t find a component where it makes sense to own the state, create a new component solely for holding the state and add it somewhere in the hierarchy above the common parent component.
In the previous step, you found two pieces of state in this application: the search input text, and the value of the checkbox.
In this example, they always appear together, so it makes sense to put them into the same place.
- Identify components that use state:
- 상태가 사용되는 컴포넌트를 찾자.
ProductTable
은 상태(검색어와 체크박스 값)에 따라 상품 목록을 필터링한다.SearchBar
는 상태(검색어와 체크박스 값)를 보여준다.
- Find their common parent: The first parent component both components share is
FilterableProductTable
.
- 공통된 부모 컴포넌트를 찾자: 두 컴포넌트가 공유하는 첫 번째 부모 컴포넌트는
FilterableProductTable
이다.
- Decide where the state lives: We’ll keep the filter text and checked state values in
FilterableProductTable
.
- 상태를 어디에 둘지 결정한다: (위의 내용을 기반으로) 검색어와 체크박스 상태 값을
FilterableProductTable
에 두면 될 것이다.
Add state to the component with the useState() Hook.
Hooks are special functions that let you “hook into” React.
- 훅은 React에 "훅(갈고리)"을 걸 수 있는 특별한 함수
Add two state variables at the top of FilterableProductTable
and specify their initial state:
filterText
, inStockOnly
)를 FilterableProductTable
컴포넌트의 위쪽에 추가하고 초기값을 정의하자.function FilterableProductTable({ products }) {
const [filterText, setFilterText] = useState('');
const [inStockOnly, setInStockOnly] = useState(false);
...
Then, pass filterText
and inStockOnly
to ProductTable
and SearchBar
as props:
filterText
와 inStockOnly
두 가지 상태를 ProductTable
과 SearchBar
에 props로 전달하자.<div>
<SearchBar
filterText={filterText}
inStockOnly={inStockOnly} />
<ProductTable
products={products}
filterText={filterText}
inStockOnly={inStockOnly} />
</div>
Notice that editing the form doesn’t work yet.
Console Error: You provided a
value
prop to a form field without anonChange
handler. This will render a read-only field.
- '
onChange
핸들러 없이 form 필드에value
prop을 전달했다'
You haven’t added any code to respond to the user actions like typing yet. This will be your final step.
Currently your app renders correctly with props and state flowing down the hierarchy.
But to change the state according to user input, you will need to support data flowing the other way: the form components deep in the hierarchy need to update the state in FilterableProductTable
.
form
컴포넌트가 상위의 FilterableProductTable
에 있는 상태를 변경할 수 있어야 한다.If you try to type or check the box in the example above, you’ll see that React ignores your input.
By writing <input value={filterText} />
, you’ve set the value
prop of the input to always be equal to the filterText
state passed in from FilterableProductTable
.
<input value={filterText} />
이라는 코드를 작성함으로써, 인풋의 value
prop이 FilterableProductTable
에서 전달된 filterText
와 동일하도록 설정되었다.Since filterText
state is never set, the input never changes.
filterText
상태는 전혀 'set'(set 메서드로 변경)되지 않았기 때문에 (입력해도) 인풋은 변하지 않는다.You want to make it so whenever the user changes the form inputs, the state updates to reflect those changes.
The state is owned by FilterableProductTable
, so only it can call setFilterText
and setInStockOnly
.
FilterableProductTable
컴포넌트에 있기 때문에 여기서 setFilterText
와 setInStockOnly
라는 set 메서드가 호출된다.To let SearchBar
update the FilterableProductTable
’s state, you need to pass these functions down to SearchBar
:
SearchBar
가 FilterableProductTable
의 상태를 갱신하도록 하기 위해 set 메서드들을 SearchBar
로 내려보내자.function FilterableProductTable({ products }) {
const [filterText, setFilterText] = useState('');
const [inStockOnly, setInStockOnly] = useState(false);
return (
<div>
<SearchBar
filterText={filterText}
inStockOnly={inStockOnly}
onFilterTextChange={setFilterText}
onInStockOnlyChange={setInStockOnly} />
...
/>
Inside the SearchBar
, you will add the onChange
event handlers and set the parent state from them:
SearchBar
에서 onChange
이벤트 핸들러를 추가하고 이걸 가지고 부모 컴포넌트의 상태(filterText
)를 변경할 것이다.<input
type="text"
value={filterText}
placeholder="Search..."
onChange={(e) => onFilterTextChange(e.target.value)} />
Now the application fully works!