From 9992b4b7cd6b32190d86084516ec20f5dfddf3ce Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Mon, 11 Nov 2019 23:59:45 +0900 Subject: [PATCH 01/14] I translated to korean for concurrent-mode-intro --- content/docs/concurrent-mode-intro.md | 96 +++++++++++++-------------- 1 file changed, 48 insertions(+), 48 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index dba52653b..ef2a186fc 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -1,89 +1,89 @@ ---- +--- id: concurrent-mode-intro -title: Introducing Concurrent Mode (Experimental) +title: 동시모드 소개(실험적) permalink: docs/concurrent-mode-intro.html next: concurrent-mode-suspense.html --- >Caution: > ->This page describes **experimental features that are [not yet available](/docs/concurrent-mode-adoption.html) in a stable release**. Don't rely on experimental builds of React in production apps. These features may change significantly and without a warning before they become a part of React. +>이 페이지는 안정된 릴리즈에서는 아직 사용할 수 없는 실험적인 특징을 설명합니다 프로덕션 앱에 있는 리액트의 실험적 빌드에 의존하지 마십시오 이 특징들은 리액트의 일부가 되기전에 경고도 없이 크게 바꿀 수도 있습니다 > ->This documentation is aimed at early adopters and people who are curious. If you're new to React, don't worry about these features -- you don't need to learn them right now. - -This page provides a theoretical overview of Concurrent Mode. **For a more practical introduction, you might want to check out the next sections:** - -* [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html) describes a new mechanism for fetching data in React components. -* [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html) shows some UI patterns made possible by Concurrent Mode and Suspense. -* [Adopting Concurrent Mode](/docs/concurrent-mode-adoption.html) explains how you can try Concurrent Mode in your project. -* [Concurrent Mode API Reference](/docs/concurrent-mode-reference.html) documents the new APIs available in experimental builds. +>이 문서는 얼리어답터들과 호기심 있는 사람들을 위해 제작된 문서입니다 리액트에 처음 접해본다면 이러한 특징들을 걱정하지 않아도 됩니다 그 특징들을 바로 배울 필요는 없습니다 + +이 페이지는 동시모드의 개요를 제시합니다 더 실용적인 설명을 위해서는 다음 섹션들을 참고하십시오 -## What Is Concurrent Mode? {#what-is-concurrent-mode} +* [데이터를 가져오기 위한 서스펜스](/docs/concurrent-mode-suspense.html) 리액트 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다 +* [동시 UI 패턴](/docs/concurrent-mode-patterns.html) 동시모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다 +* [동시모드 채택](/docs/concurrent-mode-adoption.html) 프로젝트에서 동시모드를 어떻게 사용할 수 있는지를 설명합니다 +* [동시모드 API 참조](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다 -Concurrent Mode is a set of new features that help React apps stay responsive and gracefully adjust to the user's device capabilities and network speed. +## 동시 모드란? {#what-is-concurrent-mode} -These features are still experimental and are subject to change. They are not yet a part of a stable React release, but you can try them in an experimental build. +동시모드는 리액트앱이 빠른 반응속도와 사용자의 장치 기능 및 네트워크 속도에 맞추도록 돕는 새로운 특성들의 집합체입니다 -## Blocking vs Interruptible Rendering {#blocking-vs-interruptible-rendering} +이러한 특성들은 여전히 실험적이고 수정되어야 합니다 아직 안정된 리액트 릴리즈에 일부는 아니지만, 실험적 빌드 내에서 그 특성들을 시도해볼 수 있습니다 -**To explain Concurrent Mode, we'll use version control as a metaphor.** If you work on a team, you probably use a version control system like Git and work on branches. When a branch is ready, you can merge your work into master so that other people can pull it. +## 차단 vs 인터럽트 렌더링 {#blocking-vs-interruptible-rendering} -Before version control existed, the development workflow was very different. There was no concept of branches. If you wanted to edit some files, you had to tell everyone not to touch those files until you've finished your work. You couldn't even start working on them concurrently with that person — you were literally *blocked* by them. +** 동시모드를 설명하기 위해서 버전 제어를 비유해서 설명할 것입니다 팀에서 일하고 있다면 Git과 같은 버전 제어 시스템을 사용하며 브랜치로 작업할 것 입니다 브랜치가 준비된다면 다른 사람들이 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다 -This illustrates how UI libraries, including React, typically work today. Once they start rendering an update, including creating new DOM nodes and running the code inside components, they can't interrupt this work. We'll call this approach "blocking rendering". +버전 제어가 있기 전에는, 개발 작업의 흐름이 매우 달랐습니다 브랜치라는 개념이 없어서 몇몇의 파일을 수정하려면 작업이 끝나기 전까지 다른 파일들은 건드리지않고 모든 사람들에게 말해야만 작업할 수 있었습니다 심지어는 다른 사람과 동시에 일을 시작할 수도 없었습니다 즉, 문자그대로 이러한 제한사항들에 의해 차단되었습니다 -In Concurrent Mode, rendering is not blocking. It is interruptible. This improves the user experience. It also unlocks new features that weren't possible before. Before we look at concrete examples in the [next](/docs/concurrent-mode-suspense.html) [chapters](/docs/concurrent-mode-patterns.html), we'll do a high-level overview of new features. +이는 리액트를 포함한 UI 라이브러리들이 어떻게 오늘날 작용하는 지를 보여줍니다 (새로운 DOM 노드 생성 및 컴포넌트 내에 있는 코드 실행하는 것을 포함해서) 업데이트 렌더링을 시작하면 이 일은 방해받지 않습니다 이러한 접근을 "렌더링 차단"이라고 합니다 -### Interruptible Rendering {#interruptible-rendering} +동시모드에서는, 렌더링을 인터럽트는 가능하지만 차단되지 않습니다 이는 사용자의 경험을 증가시켜주며 또한 이전에 사용할 수 없었던 특성들을 사용할 수 있도록 풀어줍니다 다음[https://reactjs.org/docs/concurrent-mode-suspense.html] 챕터[https://reactjs.org/docs/concurrent-mode-patterns.html]에서 구체적인 예시를 보기 전에, 새로운 특성들의 높은 수준의 개요를 살펴보려고 합니다. -Consider a filterable product list. Have you ever typed into a list filter and felt that it stutters on every key press? Some of the work to update the product list might be unavoidable, such as creating new DOM nodes or the browser performing layout. However, *when* and *how* we perform that work plays a big role. -A common way to work around the stutter is to "debounce" the input. When debouncing, we only update the list *after* the user stops typing. However, it can be frustrating that the UI doesn't update while we're typing. As an alternative, we could "throttle" the input, and update the list with a certain maximum frequency. But then on lower-powered devices we'd still end up with stutter. Both debouncing and throttling create a suboptimal user experience. +###인터럽트 가능한 렌더링 {#interruptible-rendering} -The reason for the stutter is simple: once rendering begins, it can't be interrupted. So the browser can't update the text input right after the key press. No matter how good a UI library (such as React) might look on a benchmark, if it uses blocking rendering, a certain amount of work in your components will always cause stutter. And, often, there is no easy fix. +필터링 가능한 제품 목록을 생각해보십시오 목록 필터에 입력한 후 모든 키를 누를 때마다 버벅거림을 느낀 적이 있습니까? 제품 목록을 업데이트하는 몇몇 작업은 불가피 할 수 있습니다 (예를 들어, 새로운 DOM 노드를 만들거나 레이아웃을 수행하는 브라우저를 만드는 작업) 그러면, 비중이 있는 그 작업을 언제 어떻게 수행할까요? -**Concurrent Mode fixes this fundamental limitation by making rendering interruptible.** This means when the user presses another key, React doesn't need to block the browser from updating the text input. Instead, it can let the browser paint an update to the input, and then continue rendering the updated list *in memory*. When the rendering is finished, React updates the DOM, and changes are reflected on the screen. +버벅거림을 해결하는 한 가지 방법은 입력을 디바운싱해주는 것입니다 디바운싱하면, 사용자는 타이핑을 멈추고 그 목록을 업데이트합니다. 하지만, 타이핑하고 있을 때 UI가 업데이트하지 않는 사실이 실망스러울 수 있습니다 이에 대한 대안으로, 입력을 조절하고 그 목록을 특정 최대 빈도수 안에서 업데이트할 수 있습니다. 그러나 저전력 장치에서는 여전히 버벅거릴 것 입니다 디 바운싱 및 쓰로틀링은 최적이 아닌 사용자 환경을 만듭니다. -Conceptually, you can think of this as React preparing every update "on a branch". Just like you can abandon work in branches or switch between them, React in Concurrent Mode can interrupt an ongoing update to do something more important, and then come back to what it was doing earlier. This technique might also remind you of [double buffering](https://wiki.osdev.org/Double_Buffering) in video games. +**동시모드는 인터럽트 가능한 렌더링을 만들어서 근본적인 제한 사항을 수정합니다. 이는 사용자가 다른 키를 누를 때, 리액트는 브라우저에 텍스트 입력을 업데이트 하는 것을 차단할 필요가 없음을 의미합니다 대신에, 리액트는 브라우저가 입력 업데이트와 메모리 내에 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다 렌더링이 끝날 때 리액트가 DOM을 업데이트하고 변경 사항들이 화면에 반영됩니다. -Concurrent Mode techniques reduce the need for debouncing and throttling in UI. Because rendering is interruptible, React doesn't need to artificially *delay* work to avoid stutter. It can start rendering right away, but interrupt this work when needed to keep the app responsive. +개념상으로, 리액트가 지점별 모든 업데이트를 준비하는 것으로 생각할 수 있습니다 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, 동시모드 내에 리액트는 더 중요한 일을 위해 진행 중인 업데이트를 중단하고 이전 작업으로 돌아갈 수도 있습니다 또한 이 기술은 비디오 게임에서 이중 버퍼링을 떠오르게 합니다. -### Intentional Loading Sequences {#intentional-loading-sequences} +동시모드 기술은 UI에서 디바운싱과 스로틀링의 필요성을 줄입니다 렌더링은 중단이 가능하기 때문에 버벅거림을 피하고자 일부러 작업을 지연시킬 필요가 없습니다 리액트가 렌더링을 즉시 시작할 수 있지만 앱이 즉각적으로 반응하도록 요구될 때는 작업이 중단될 수도 있습니다. + -We've said before that Concurrent Mode is like React working "on a branch". Branches are useful not only for short-term fixes, but also for long-running features. Sometimes you might work on a feature, but it could take weeks before it's in a "good enough state" to merge into master. This side of our version control metaphor applies to rendering too. +### 의도적인 로딩 시퀀스 {#intentional-loading-sequences} -Imagine we're navigating between two screens in an app. Sometimes, we might not have enough code and data loaded to show a "good enough" loading state to the user on the new screen. Transitioning to an empty screen or a large spinner can be a jarring experience. However, it's also common that the necessary code and data doesn't take too long to fetch. **Wouldn't it be nicer if React could stay on the old screen for a little longer, and "skip" the "bad loading state" before showing the new screen?** +우리는 동시모드는 브랜치에서 React 작업과 같다고 전에 말했습니다. 브랜치는 단기적인 수정을 할 때뿐만 아니라 장기적인 기능에도 유용합니다. 가끔 기능에 대해 작업을 할 수도 있습니다. 하지만 마스터로 병합할 수 있는 적합한 상태가 되기까지는 몇 주가 걸릴 수 있습니다. 버전 관리 비유의 측면은 렌더링에도 적용됩니다. -While this is possible today, it can be difficult to orchestrate. In Concurrent Mode, this feature is built-in. React starts preparing the new screen in memory first — or, as our metaphor goes, "on a different branch". So React can wait before updating the DOM so that more content can load. In Concurrent Mode, we can tell React to keep showing the old screen, fully interactive, with an inline loading indicator. And when the new screen is ready, React can take us to it. +한번 앱에서 두 화면 사이를 탐색한다고 가정해보겠습니다. 때로는 새 화면에서 사용자에게 좋은 로딩 상태를 보여주기 위해 충분한 코드와 데이터를 불러오지 못 할 수 있습니다. 빈 화면이나 큰 스피너로 전환하는 것은 어려운 경험이 될 수 있습니다. 하지만 필요한 코드와 데이터를 가져오는 데 너무 오래 걸리지 않는 것 또한 일반적입니다. React가 기존 화면에서 조금 더 오래 머물 수 있고 새 화면을 보여주기 전에 안 좋은 로딩 상태를 건너뛸 수 있게 해준다면 더 좋지 않겠습니까?** -### Concurrency {#concurrency} +오늘날 이것이 가능하긴 하지만 조정하기는 어려울 수 있습니다. 동시모드에서는 이 기능이 내장되어 있습니다. React는 먼저 메모리에서 새로운 화면을 준비하기 시작하는데 또는 우리의 비유처럼 다른 브랜치에서 시작합니다. 따라서 React는 더 많은 콘텐츠를 불러올 수 있도록 DOM을 업데이트하기 전에 기다릴 수 있습니다. 동시모드에서 React에 인라인 표시기와 함께 완전히 상호작용하여 이전 화면을 계속 표시하도록 지시할 수 있습니다. 그리고 새로운 화면이 준비되면 React는 우리를 그곳으로 데려갈 수 있습니다. -Let's recap the two examples above and see how Concurrent Mode unifies them. **In Concurrent Mode, React can work on several state updates *concurrently*** — just like branches let different team members work independently: +### 동시성 {#concurrency} -* For CPU-bound updates (such as creating DOM nodes and running component code), concurrency means that a more urgent update can "interrupt" rendering that has already started. -* For IO-bound updates (such as fetching code or data from the network), concurrency means that React can start rendering in memory even before all the data arrives, and skip showing jarring empty loading states. +위의 두 가지 예를 살펴보고 동시모드가 어떻게 통합되는지 살펴보겠습니다. 동시모드에서 React는 여러 팀 구성원이 독립적으로 작업할 수 있도록 하는 브랜치처럼 여러 상태 업데이트를 동시에 수행 할 수 있습니다. -Importantly, the way you *use* React is the same. Concepts like components, props, and state fundamentally work the same way. When you want to update the screen, you set the state. +* CPU 바운드 업데이트(예: DOM 노드 만들기 및 컴포넌트 코드 실행)의 경우 동시성은 더욱 긴급한 업데이트가 이미 시작된 렌더링을 중단 할 수 있음을 의미합니다. +* 바운드 업데이트(예: 네트워크에서 코드나 데이터를 가져오는 것)의 경우 동시성은 모든 데이터가 도착하기 전에 React가 메모리에서 렌더링을 시작할 수 있으며 빈 로딩 상태가 표시되는 것을 건너뛰는 것을 의미합니다. -React uses a heuristic to decide how "urgent" an update is, and lets you adjust it with a few lines of code so that you can achieve the desired user experience for every interaction. +중요한 것은 React를 사용하는 방식이 똑같다는 것입니다. 컴포넌트, 소품 및 상태와 같은 개념은 근본적으로 동일한 방식으로 작동합니다. 화면을 업데이트하려면 상태를 설정합니다. -## Putting Research into Production {#putting-research-into-production} +React는 휴리스틱을 사용하여 업데이트의 급함의 정도를 결정하고, 사용자가 모든 상호작용에 대해 원하는 사용자의 경험을 얻을 수 있도록 몇 줄의 코드를 조정하도록 합니다. -There is a common theme around Concurrent Mode features. **Its mission is to help integrate the findings from the Human-Computer Interaction research into real UIs.** +## 연구를 생산에 투입 {#putting-research-into-production} -For example, research shows that displaying too many intermediate loading states when transitioning between screens makes a transition feel *slower*. This is why Concurrent Mode shows new loading states on a fixed "schedule" to avoid jarring and too frequent updates. +**Concurrent Mode 기능에 대한 공통 주제들이 있습니다. 이것의 목표는 사람-컴퓨터 간 상호작용에 대한 조사를 실제 UI에 통합시키는 것을 돕는 것입니다. -Similarly, we know from research that interactions like hover and text input need to be handled within a very short period of time, while clicks and page transitions can wait a little longer without feeling laggy. The different "priorities" that Concurrent Mode uses internally roughly correspond to the interaction categories in the human perception research. +예를 들어, 조사에 따르면 화면 간 전환에서 중간 로딩 상태를 너무 많이 배치하는 것은 전환 자체를 더 *느리게* 느끼게 만든다고 합니다. 이것이 Concurrent Mode에서 고정된 "스케줄"에 새로운 로드 상태를 표시하여 부조화가 발생하는 것 또는 불필요하게 많이 업데이트되는 것을 피하고자 하는 이유입니다. -Teams with a strong focus on user experience sometimes solve similar problems with one-off solutions. However, those solutions rarely survive for a long time, as they're hard to maintain. With Concurrent Mode, our goal is to bake the UI research findings into the abstraction itself, and provide idiomatic ways to use them. As a UI library, React is well-positioned to do that. +마찬가지로 조사 결과에 따르면, 호버나 텍스트 입력 같은 상호 작용은 아주 짧은 시간 안에 처리되어야 하지만, 클릭이나 페이지 전환은 지루한 느낌 없이 조금 더 오래 기다릴 수 있습니다. Concurrent Mode 내부적으로 사용하는 다른 "우선순위"는 사람들의 인식에 대한 조사에서의 상호 작용에 대한 부분과 대략 일치합니다. -## Next Steps {#next-steps} +UX(사용자 경험)에 중점을 둔 팀은 가끔 이러한 비슷한 문제들을 일회성 솔루션으로 해결하곤 합니다. 그러나, 그런 솔루션들은 오래 지속되기가 어렵고, 유지하기도 어렵습니다. Concurrent Mode에선, UI 조사 결과를 추상화시키고, 그것을 사용할 관용적인 방법을 제공하는 것입니다. UI 라이브러리로서 React는, 이것을 하기 위한 배치가 잘 되어 있습니다. + +## 다음 단계 {#next-steps} -Now you know what Concurrent Mode is all about! +**이제 Concurrent Mode에 대해 모두 알게 되었습니다! -On the next pages, you'll learn more details about specific topics: +**다음 페이지에서는 특정 주제에 대한 자세한 내용을 배웁니다: -* [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html) describes a new mechanism for fetching data in React components. -* [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html) shows some UI patterns made possible by Concurrent Mode and Suspense. -* [Adopting Concurrent Mode](/docs/concurrent-mode-adoption.html) explains how you can try Concurrent Mode in your project. -* [Concurrent Mode API Reference](/docs/concurrent-mode-reference.html) documents the new APIs available in experimental builds. +* [데이터를 가져오기 위한 서스펜스](/docs/concurrent-mode-suspense.html) 리액트 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다 +* [동시 UI 패턴](/docs/concurrent-mode-patterns.html) 동시모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다 +* [동시모드 채택](/docs/concurrent-mode-adoption.html) 프로젝트에서 동시모드를 어떻게 사용할 수 있는지를 설명합니다 +* [동시모드 API 참조](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다 From 202cca81e0a86b2c062589df6f013170c9444c5d Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Tue, 12 Nov 2019 13:25:06 +0900 Subject: [PATCH 02/14] Tranlating to korean for concourrent-mode-intro.md --- content/docs/concurrent-mode-intro.md | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index ef2a186fc..5b3836e4a 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -5,13 +5,13 @@ permalink: docs/concurrent-mode-intro.html next: concurrent-mode-suspense.html --- ->Caution: +>주의사항: > ->이 페이지는 안정된 릴리즈에서는 아직 사용할 수 없는 실험적인 특징을 설명합니다 프로덕션 앱에 있는 리액트의 실험적 빌드에 의존하지 마십시오 이 특징들은 리액트의 일부가 되기전에 경고도 없이 크게 바꿀 수도 있습니다 +>이 페이지는 **안정된 릴리즈에서는 [아직 사용할 수 없는] 실험적인 특징을 설명합니다 프로덕션 앱에 있는 리액트의 실험적 빌드에 의존하지 마세요 이 특징들은 리액트에 병합 되기전에 경고도 없이 크게 바꿀 수도 있습니다 > >이 문서는 얼리어답터들과 호기심 있는 사람들을 위해 제작된 문서입니다 리액트에 처음 접해본다면 이러한 특징들을 걱정하지 않아도 됩니다 그 특징들을 바로 배울 필요는 없습니다 -이 페이지는 동시모드의 개요를 제시합니다 더 실용적인 설명을 위해서는 다음 섹션들을 참고하십시오 +이 페이지는 동시모드의 개요를 제시합니다 **더 실용적인 설명을 위해서는 다음 섹션들을 참고하세요** * [데이터를 가져오기 위한 서스펜스](/docs/concurrent-mode-suspense.html) 리액트 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다 * [동시 UI 패턴](/docs/concurrent-mode-patterns.html) 동시모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다 @@ -22,7 +22,7 @@ next: concurrent-mode-suspense.html 동시모드는 리액트앱이 빠른 반응속도와 사용자의 장치 기능 및 네트워크 속도에 맞추도록 돕는 새로운 특성들의 집합체입니다 -이러한 특성들은 여전히 실험적이고 수정되어야 합니다 아직 안정된 리액트 릴리즈에 일부는 아니지만, 실험적 빌드 내에서 그 특성들을 시도해볼 수 있습니다 +이러한 특성들은 여전히 실험적이며 수정되어야 하는 부분이 있습니다 아직 안정된 리액트 릴리즈에 병합된 것은 아니지만, 실험적 빌드 내에서 그 특성들을 시도해볼 수는 있습니다 ## 차단 vs 인터럽트 렌더링 {#blocking-vs-interruptible-rendering} @@ -34,20 +34,18 @@ next: concurrent-mode-suspense.html 동시모드에서는, 렌더링을 인터럽트는 가능하지만 차단되지 않습니다 이는 사용자의 경험을 증가시켜주며 또한 이전에 사용할 수 없었던 특성들을 사용할 수 있도록 풀어줍니다 다음[https://reactjs.org/docs/concurrent-mode-suspense.html] 챕터[https://reactjs.org/docs/concurrent-mode-patterns.html]에서 구체적인 예시를 보기 전에, 새로운 특성들의 높은 수준의 개요를 살펴보려고 합니다. - ###인터럽트 가능한 렌더링 {#interruptible-rendering} 필터링 가능한 제품 목록을 생각해보십시오 목록 필터에 입력한 후 모든 키를 누를 때마다 버벅거림을 느낀 적이 있습니까? 제품 목록을 업데이트하는 몇몇 작업은 불가피 할 수 있습니다 (예를 들어, 새로운 DOM 노드를 만들거나 레이아웃을 수행하는 브라우저를 만드는 작업) 그러면, 비중이 있는 그 작업을 언제 어떻게 수행할까요? 버벅거림을 해결하는 한 가지 방법은 입력을 디바운싱해주는 것입니다 디바운싱하면, 사용자는 타이핑을 멈추고 그 목록을 업데이트합니다. 하지만, 타이핑하고 있을 때 UI가 업데이트하지 않는 사실이 실망스러울 수 있습니다 이에 대한 대안으로, 입력을 조절하고 그 목록을 특정 최대 빈도수 안에서 업데이트할 수 있습니다. 그러나 저전력 장치에서는 여전히 버벅거릴 것 입니다 디 바운싱 및 쓰로틀링은 최적이 아닌 사용자 환경을 만듭니다. -**동시모드는 인터럽트 가능한 렌더링을 만들어서 근본적인 제한 사항을 수정합니다. 이는 사용자가 다른 키를 누를 때, 리액트는 브라우저에 텍스트 입력을 업데이트 하는 것을 차단할 필요가 없음을 의미합니다 대신에, 리액트는 브라우저가 입력 업데이트와 메모리 내에 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다 렌더링이 끝날 때 리액트가 DOM을 업데이트하고 변경 사항들이 화면에 반영됩니다. +**동시모드는 인터럽트 가능한 렌더링을 만들어서 근본적인 문제를 수정합니다. 이는 사용자가 다른 키를 누를 때, 리액트는 브라우저에 텍스트 입력을 업데이트 하는 것을 차단할 필요가 없음을 의미합니다 대신에, 리액트는 브라우저가 입력 업데이트와 메모리 내에 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다 렌더링이 끝날 때 리액트가 DOM을 업데이트하고 변경 사항들이 화면에 반영됩니다. -개념상으로, 리액트가 지점별 모든 업데이트를 준비하는 것으로 생각할 수 있습니다 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, 동시모드 내에 리액트는 더 중요한 일을 위해 진행 중인 업데이트를 중단하고 이전 작업으로 돌아갈 수도 있습니다 또한 이 기술은 비디오 게임에서 이중 버퍼링을 떠오르게 합니다. +개념상으로, 리액트가 지점별 모든 업데이트를 준비하는 것으로 생각할 수 있습니다 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, 동시모드 내에 리액트는 더 중요한 일을 위해 진행 중인 업데이트를 중단하고 이전 작업으로 돌아갈 수도 있습니다 또한 이 기술은 비디오 게임에서 [이중 버퍼링](https://wiki.osdev.org/Double_Buffering)을 떠오르게 합니다. 동시모드 기술은 UI에서 디바운싱과 스로틀링의 필요성을 줄입니다 렌더링은 중단이 가능하기 때문에 버벅거림을 피하고자 일부러 작업을 지연시킬 필요가 없습니다 리액트가 렌더링을 즉시 시작할 수 있지만 앱이 즉각적으로 반응하도록 요구될 때는 작업이 중단될 수도 있습니다. - ### 의도적인 로딩 시퀀스 {#intentional-loading-sequences} 우리는 동시모드는 브랜치에서 React 작업과 같다고 전에 말했습니다. 브랜치는 단기적인 수정을 할 때뿐만 아니라 장기적인 기능에도 유용합니다. 가끔 기능에 대해 작업을 할 수도 있습니다. 하지만 마스터로 병합할 수 있는 적합한 상태가 되기까지는 몇 주가 걸릴 수 있습니다. 버전 관리 비유의 측면은 렌더링에도 적용됩니다. @@ -63,25 +61,25 @@ next: concurrent-mode-suspense.html * CPU 바운드 업데이트(예: DOM 노드 만들기 및 컴포넌트 코드 실행)의 경우 동시성은 더욱 긴급한 업데이트가 이미 시작된 렌더링을 중단 할 수 있음을 의미합니다. * 바운드 업데이트(예: 네트워크에서 코드나 데이터를 가져오는 것)의 경우 동시성은 모든 데이터가 도착하기 전에 React가 메모리에서 렌더링을 시작할 수 있으며 빈 로딩 상태가 표시되는 것을 건너뛰는 것을 의미합니다. -중요한 것은 React를 사용하는 방식이 똑같다는 것입니다. 컴포넌트, 소품 및 상태와 같은 개념은 근본적으로 동일한 방식으로 작동합니다. 화면을 업데이트하려면 상태를 설정합니다. +중요한 것은 React를 *사용*하는 방식이 똑같다는 것입니다. 컴포넌트, 소품 및 상태와 같은 개념은 근본적으로 동일한 방식으로 작동합니다. 화면을 업데이트하려면 상태를 설정합니다. React는 휴리스틱을 사용하여 업데이트의 급함의 정도를 결정하고, 사용자가 모든 상호작용에 대해 원하는 사용자의 경험을 얻을 수 있도록 몇 줄의 코드를 조정하도록 합니다. -## 연구를 생산에 투입 {#putting-research-into-production} +## 생산에 연구를 더하기 {#putting-research-into-production} -**Concurrent Mode 기능에 대한 공통 주제들이 있습니다. 이것의 목표는 사람-컴퓨터 간 상호작용에 대한 조사를 실제 UI에 통합시키는 것을 돕는 것입니다. +Concurrent Mode 기능에 대한 공통 주제들이 있습니다. **이것의 목표는 사람-컴퓨터 간 상호작용에 대한 조사를 실제 UI에 통합시키는 것을 돕는 것입니다. ** 예를 들어, 조사에 따르면 화면 간 전환에서 중간 로딩 상태를 너무 많이 배치하는 것은 전환 자체를 더 *느리게* 느끼게 만든다고 합니다. 이것이 Concurrent Mode에서 고정된 "스케줄"에 새로운 로드 상태를 표시하여 부조화가 발생하는 것 또는 불필요하게 많이 업데이트되는 것을 피하고자 하는 이유입니다. -마찬가지로 조사 결과에 따르면, 호버나 텍스트 입력 같은 상호 작용은 아주 짧은 시간 안에 처리되어야 하지만, 클릭이나 페이지 전환은 지루한 느낌 없이 조금 더 오래 기다릴 수 있습니다. Concurrent Mode 내부적으로 사용하는 다른 "우선순위"는 사람들의 인식에 대한 조사에서의 상호 작용에 대한 부분과 대략 일치합니다. +마찬가지로 조사 결과에 따르면, 호버나 텍스트 입력 같은 상호 작용은 아주 짧은 시간 안에 처리되어야 하는 반면에, 클릭이나 페이지 전환은 지루한 느낌 없이 조금 더 오래 기다릴 수 있습니다. Concurrent Mode 내부적으로 사용하는 다른 "우선순위"는 사람들의 인식에 대한 조사에서의 상호 작용에 대한 부분과 대략 일치합니다. UX(사용자 경험)에 중점을 둔 팀은 가끔 이러한 비슷한 문제들을 일회성 솔루션으로 해결하곤 합니다. 그러나, 그런 솔루션들은 오래 지속되기가 어렵고, 유지하기도 어렵습니다. Concurrent Mode에선, UI 조사 결과를 추상화시키고, 그것을 사용할 관용적인 방법을 제공하는 것입니다. UI 라이브러리로서 React는, 이것을 하기 위한 배치가 잘 되어 있습니다. ## 다음 단계 {#next-steps} -**이제 Concurrent Mode에 대해 모두 알게 되었습니다! +이제 Concurrent Mode에 대해 모두 알게 되었습니다! -**다음 페이지에서는 특정 주제에 대한 자세한 내용을 배웁니다: +다음 페이지에서는 특정 주제에 대한 자세한 내용을 배웁니다: * [데이터를 가져오기 위한 서스펜스](/docs/concurrent-mode-suspense.html) 리액트 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다 * [동시 UI 패턴](/docs/concurrent-mode-patterns.html) 동시모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다 From f091ac53c3c1c1aab316681e441c1a8657bf5c92 Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Sun, 17 Nov 2019 19:52:31 +0900 Subject: [PATCH 03/14] Modified concurrent-mode-intro.md --- content/docs/concurrent-mode-intro.md | 86 ++++++++++++++------------- 1 file changed, 44 insertions(+), 42 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 5b3836e4a..dc95ff07c 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -1,87 +1,89 @@ ---- +--- id: concurrent-mode-intro -title: 동시모드 소개(실험적) +title: Concurrent모드 소개(실험적) permalink: docs/concurrent-mode-intro.html next: concurrent-mode-suspense.html --- + >주의사항: > ->이 페이지는 **안정된 릴리즈에서는 [아직 사용할 수 없는] 실험적인 특징을 설명합니다 프로덕션 앱에 있는 리액트의 실험적 빌드에 의존하지 마세요 이 특징들은 리액트에 병합 되기전에 경고도 없이 크게 바꿀 수도 있습니다 +>이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는] 실험적인 기능들에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 일부가 되기 전에 경고 없이 크게 변경될 수 있습니다. > ->이 문서는 얼리어답터들과 호기심 있는 사람들을 위해 제작된 문서입니다 리액트에 처음 접해본다면 이러한 특징들을 걱정하지 않아도 됩니다 그 특징들을 바로 배울 필요는 없습니다 - -이 페이지는 동시모드의 개요를 제시합니다 **더 실용적인 설명을 위해서는 다음 섹션들을 참고하세요** +>이 문서는 얼리어답터들과 궁금해하시는 분들을 위해 제작된 문서입니다. React에 처음 접해본다면 이러한 기능들을 걱정하지 않아도 됩니다. 그 기능들을 바로 배울 필요는 없습니다. + +이 페이지는 Concurrent 모드의 이론적인 개요를 제시합니다 **더 실용적인 설명을 위해서는 다음 섹션들을 참고하세요** -* [데이터를 가져오기 위한 서스펜스](/docs/concurrent-mode-suspense.html) 리액트 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다 -* [동시 UI 패턴](/docs/concurrent-mode-patterns.html) 동시모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다 -* [동시모드 채택](/docs/concurrent-mode-adoption.html) 프로젝트에서 동시모드를 어떻게 사용할 수 있는지를 설명합니다 -* [동시모드 API 참조](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다 +* [데이터를 가져오기 위한 서스펜스](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. +* [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다. +* [Concurrent 모드 채택](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드를 어떻게 사용할 수 있는지를 설명합니다. +* [Concurrent 모드 API reference](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다. -## 동시 모드란? {#what-is-concurrent-mode} +## Concurrent 모드란? {#what-is-concurrent-mode} -동시모드는 리액트앱이 빠른 반응속도와 사용자의 장치 기능 및 네트워크 속도에 맞추도록 돕는 새로운 특성들의 집합체입니다 +Concurrent모드는 React 앱이 빠른 반응속도를 유지하도록 하고 사용자의 장치 기능 및 네트워크 속도에 적절하게 맞추도록 돕는 새로운 기능들의 집합체입니다 -이러한 특성들은 여전히 실험적이며 수정되어야 하는 부분이 있습니다 아직 안정된 리액트 릴리즈에 병합된 것은 아니지만, 실험적 빌드 내에서 그 특성들을 시도해볼 수는 있습니다 +이 기능들은 여전히 실험적이며 수정되어야 합니다. 아직 안정된 React 배포판에 일부가 된 것은 아니지만, 실험 배포판에서 그 기능들을 시도해볼 수는 있습니다 ## 차단 vs 인터럽트 렌더링 {#blocking-vs-interruptible-rendering} -** 동시모드를 설명하기 위해서 버전 제어를 비유해서 설명할 것입니다 팀에서 일하고 있다면 Git과 같은 버전 제어 시스템을 사용하며 브랜치로 작업할 것 입니다 브랜치가 준비된다면 다른 사람들이 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다 +** Concurrent 모드를 설명하기 위해서 버전 제어를 비유해서 설명할 것입니다. 팀에서 일하고 있다면 Git과 같은 버전 제어 시스템을 사용하며 브랜치로 작업할 것입니다 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다 -버전 제어가 있기 전에는, 개발 작업의 흐름이 매우 달랐습니다 브랜치라는 개념이 없어서 몇몇의 파일을 수정하려면 작업이 끝나기 전까지 다른 파일들은 건드리지않고 모든 사람들에게 말해야만 작업할 수 있었습니다 심지어는 다른 사람과 동시에 일을 시작할 수도 없었습니다 즉, 문자그대로 이러한 제한사항들에 의해 차단되었습니다 +버전 제어가 있기 전에는, 개발 작업의 흐름이 지금과는 매우 달랐습니다. 브랜치라는 개념이 없어서 몇몇 파일을 수정하려면 그 파일들을 수정 작업을 완료하기 전까지 작업하면 안 된다고 모든 사람에게 말해야 했습니다 심지어는 다른 사람과 동시에 일을 시작할 수도 없었습니다 즉, 문자그대로 이러한 제한사항들에 의해 *차단*되었습니다 -이는 리액트를 포함한 UI 라이브러리들이 어떻게 오늘날 작용하는 지를 보여줍니다 (새로운 DOM 노드 생성 및 컴포넌트 내에 있는 코드 실행하는 것을 포함해서) 업데이트 렌더링을 시작하면 이 일은 방해받지 않습니다 이러한 접근을 "렌더링 차단"이라고 합니다 +이는 React를 포함한 UI 라이브러리들이 어떻게 오늘날 작용하는지를 설명해줍니다. 업데이트를 렌더링(새로운 DOM 노드 생성 및 컴포넌트 내에 있는 코드 실행하는 것을 포함해서)을 시작하면 이 일은 방해받지 않습니다. 이러한 접근을 "차단 렌더링"이라고 합니다 -동시모드에서는, 렌더링을 인터럽트는 가능하지만 차단되지 않습니다 이는 사용자의 경험을 증가시켜주며 또한 이전에 사용할 수 없었던 특성들을 사용할 수 있도록 풀어줍니다 다음[https://reactjs.org/docs/concurrent-mode-suspense.html] 챕터[https://reactjs.org/docs/concurrent-mode-patterns.html]에서 구체적인 예시를 보기 전에, 새로운 특성들의 높은 수준의 개요를 살펴보려고 합니다. +Concurrent 모드에서는, 렌더링은 차단되지 않으나 인터럽트는 가능합니다. 이는 사용자의 경험을 증가시켜주며 또한 이전에 사용할 수 없었던 기능들을 사용할 수 있도록 만들어줍니다. 다음[https://reactjs.org/docs/concurrent-mode-suspense.html] 챕터[https://reactjs.org/docs/concurrent-mode-patterns.html]에서 구체적인 예시를 보기 전에, 새로운 기능들의 높은 수준의 개요를 해보려고 합니다. ###인터럽트 가능한 렌더링 {#interruptible-rendering} -필터링 가능한 제품 목록을 생각해보십시오 목록 필터에 입력한 후 모든 키를 누를 때마다 버벅거림을 느낀 적이 있습니까? 제품 목록을 업데이트하는 몇몇 작업은 불가피 할 수 있습니다 (예를 들어, 새로운 DOM 노드를 만들거나 레이아웃을 수행하는 브라우저를 만드는 작업) 그러면, 비중이 있는 그 작업을 언제 어떻게 수행할까요? +필터링 가능한 제품 목록을 생각해보세요. 목록 필터에 입력하고 모든 키를 누를 때마다 버벅거림을 느낀 적이 있습니까? 제품 목록을 업데이트하는 몇몇 작업은 불가피할 수 있습니다. (예를 들어, 새로운 DOM 노드를 만들거나 레이아웃을 수행하는 브라우저를 만드는 작업) 그러면, *언제* *어떻게* 이런 비중 있는 작업을 수행할까요? -버벅거림을 해결하는 한 가지 방법은 입력을 디바운싱해주는 것입니다 디바운싱하면, 사용자는 타이핑을 멈추고 그 목록을 업데이트합니다. 하지만, 타이핑하고 있을 때 UI가 업데이트하지 않는 사실이 실망스러울 수 있습니다 이에 대한 대안으로, 입력을 조절하고 그 목록을 특정 최대 빈도수 안에서 업데이트할 수 있습니다. 그러나 저전력 장치에서는 여전히 버벅거릴 것 입니다 디 바운싱 및 쓰로틀링은 최적이 아닌 사용자 환경을 만듭니다. +버벅거림을 해결하는 한 가지 방법은 입력을 디바운싱해주는 것입니다 디바운싱하면, 사용자가 타이핑을 멈추고 나서만 목록을 업데이트합니다. 하지만, 타이핑하고 있을 때 UI가 업데이트하지 않는 사실이 실망스러울 수 있습니다. 이에 대한 대안으로, 입력을 “스로틀”하고 목록을 특정 최대 빈도수로 업데이트 할 수 있습니다. 그러나 저전력 장치에서는 여전히 버벅거릴 것입니다. 디 바운싱 및 쓰로틀링은 둘 다 최적이 아닌 사용자 환경을 만듭니다. -**동시모드는 인터럽트 가능한 렌더링을 만들어서 근본적인 문제를 수정합니다. 이는 사용자가 다른 키를 누를 때, 리액트는 브라우저에 텍스트 입력을 업데이트 하는 것을 차단할 필요가 없음을 의미합니다 대신에, 리액트는 브라우저가 입력 업데이트와 메모리 내에 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다 렌더링이 끝날 때 리액트가 DOM을 업데이트하고 변경 사항들이 화면에 반영됩니다. +버벅거림의 이유는 간단합니다: 렌더링이 시작되면 중간에 중단될 수 없기 때문입니다. 그래서 그 브라우저는 텍스트 입력을 키를 누르는 즉시 업데이트할 수 없습니다. 벤치마크에서 UI 라이브러리( 예를 들어 React)가 아무리 잘 보일지라도, 차단 렌더링을 사용하고 컴포넌트의 일정량 작업을 하면 항상 버벅거림을 초래할 것입니다. 그리고 종종 이에 대한 쉬운 해결책이 없습니다. -개념상으로, 리액트가 지점별 모든 업데이트를 준비하는 것으로 생각할 수 있습니다 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, 동시모드 내에 리액트는 더 중요한 일을 위해 진행 중인 업데이트를 중단하고 이전 작업으로 돌아갈 수도 있습니다 또한 이 기술은 비디오 게임에서 [이중 버퍼링](https://wiki.osdev.org/Double_Buffering)을 떠오르게 합니다. +**Concurrent 모드는 렌더링을 인터럽트 가능하도록 만듦으로써 근본적인 문제를 수정합니다. 이러한 사실은 사용자가 다른 키를 누를 때, React는 브라우저에 텍스트 입력을 업데이트하는 것을 차단할 필요가 없음을 의미합니다. 대신에, React는 브라우저가 입력에 대한 업데이트를 paint하고 *메모리 내에* 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다. 렌더링이 끝나면 React는 DOM을 업데이트하고 변경 사항들이 화면에 반영합니다. + +개념상으로, React가 지점별 모든 업데이트를 준비하는 것으로 생각할 수 있습니다. 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, Concurrent모드 내에 React는 더 중요한 일을 위해 진행 중인 업데이트를 중단할 수 있고 그리고서 이전 작업으로 돌아갈 수도 있습니다. 이 기술은 비디오 게임에서 [이중 버퍼링](https://wiki.osdev.org/Double_Buffering)을 떠오르게끔 할 수도 있습니다. + +Concurrent모드 기술은 UI에서 디바운싱과 스로틀링의 필요성을 줄입니다 렌더링은 중단이 가능하기 때문에 버벅거림을 피하고자 일부러 작업을 지연시킬 필요가 없습니다. React는 렌더링을 즉시 시작할 수 있지만, 앱의 즉각적인 반응성이 요구될 때는 이 작업을 중단할 수도 있습니다. -동시모드 기술은 UI에서 디바운싱과 스로틀링의 필요성을 줄입니다 렌더링은 중단이 가능하기 때문에 버벅거림을 피하고자 일부러 작업을 지연시킬 필요가 없습니다 리액트가 렌더링을 즉시 시작할 수 있지만 앱이 즉각적으로 반응하도록 요구될 때는 작업이 중단될 수도 있습니다. - ### 의도적인 로딩 시퀀스 {#intentional-loading-sequences} -우리는 동시모드는 브랜치에서 React 작업과 같다고 전에 말했습니다. 브랜치는 단기적인 수정을 할 때뿐만 아니라 장기적인 기능에도 유용합니다. 가끔 기능에 대해 작업을 할 수도 있습니다. 하지만 마스터로 병합할 수 있는 적합한 상태가 되기까지는 몇 주가 걸릴 수 있습니다. 버전 관리 비유의 측면은 렌더링에도 적용됩니다. +Concurrent 모드는 브랜치에서 React 작업과 같다고 전에 말했습니다. 브랜치는 단기적인 수정을 할 때뿐만 아니라 장기적인 기능에도 유용합니다. 가끔 기능에 대해 작업을 할 수도 있습니다. 하지만 마스터로 병합할 수 있는 적합한 스테이트가 되기까지 몇 주가 걸릴 수 있습니다. 버전 관리 비유의 측면은 렌더링에도 적용됩니다. -한번 앱에서 두 화면 사이를 탐색한다고 가정해보겠습니다. 때로는 새 화면에서 사용자에게 좋은 로딩 상태를 보여주기 위해 충분한 코드와 데이터를 불러오지 못 할 수 있습니다. 빈 화면이나 큰 스피너로 전환하는 것은 어려운 경험이 될 수 있습니다. 하지만 필요한 코드와 데이터를 가져오는 데 너무 오래 걸리지 않는 것 또한 일반적입니다. React가 기존 화면에서 조금 더 오래 머물 수 있고 새 화면을 보여주기 전에 안 좋은 로딩 상태를 건너뛸 수 있게 해준다면 더 좋지 않겠습니까?** +한번 앱에서 두 화면 사이를 탐색한다고 가정해보겠습니다. 때로는 새 화면에서 사용자에게 좋은 로딩 스테이트를 보여주기 위해 충분한 코드와 데이터를 불러오지 못 할 수 있습니다. 빈 화면이나 큰 스피너로 전환하는 것은 어려운 경험이 될 수 있습니다. 하지만 필요한 코드와 데이터를 가져오는 데 너무 오래 걸리지 않는 것 또한 흔한 일입니다. **React가 기존 화면에서 조금 더 오래 머물 수 있고 새 화면을 보여주기 전에 안 좋은 로딩 스테이트를 건너뛸 수 있게 해준다면 더 좋지 않겠습니까?** -오늘날 이것이 가능하긴 하지만 조정하기는 어려울 수 있습니다. 동시모드에서는 이 기능이 내장되어 있습니다. React는 먼저 메모리에서 새로운 화면을 준비하기 시작하는데 또는 우리의 비유처럼 다른 브랜치에서 시작합니다. 따라서 React는 더 많은 콘텐츠를 불러올 수 있도록 DOM을 업데이트하기 전에 기다릴 수 있습니다. 동시모드에서 React에 인라인 표시기와 함께 완전히 상호작용하여 이전 화면을 계속 표시하도록 지시할 수 있습니다. 그리고 새로운 화면이 준비되면 React는 우리를 그곳으로 데려갈 수 있습니다. +오늘날 이것이 가능하긴 하지만 조정하기는 어려울 수 있습니다. Concurrent 모드에서는 이 기능이 내장되어 있습니다. React는 먼저 메모리에서 새로운 화면을 준비하기 시작하는데 또는 우리의 비유처럼 다른 브랜치에서 시작합니다. 따라서 React는 더 많은 콘텐츠를 불러올 수 있도록 DOM을 업데이트하기 전에 기다릴 수 있습니다. Concurrent 모드에서 React에 인라인 표시기와 함께 완전히 상호작용하여 이전 화면을 계속 표시하도록 지시할 수 있습니다. 그리고 새로운 화면이 준비되면 React는 그곳으로 데려갈 수 있습니다. ### 동시성 {#concurrency} -위의 두 가지 예를 살펴보고 동시모드가 어떻게 통합되는지 살펴보겠습니다. 동시모드에서 React는 여러 팀 구성원이 독립적으로 작업할 수 있도록 하는 브랜치처럼 여러 상태 업데이트를 동시에 수행 할 수 있습니다. +위의 두 가지 예시를 살펴보고 Concurrent 모드가 어떻게 통합되는지 살펴보겠습니다. **Concurrent 모드에서 React는** 여러 팀 구성원이 독립적으로 작업할 수 있도록 하는 브랜치처럼 **여러 스테이트 업데이트를 *동시에* 수행 할 수 있습니다**. + +* CPU 바운드 업데이트(예를 들어 DOM 노드 만들기 및 컴포넌트 코드 실행)의 경우 Concurrency는 더욱 긴급한 업데이트가 이미 시작된 렌더링을 중단 할 수 있음을 의미합니다. +* IO 바운드 업데이트(예를 들어 네트워크에서 코드나 데이터를 가져오는 것)의 경우 Concurrency는 모든 데이터가 도착하기 전에 React가 메모리에서 렌더링을 시작할 수 있으며 빈 로딩 스테이트가 표시되는 것을 건너뜀을 의미합니다. -* CPU 바운드 업데이트(예: DOM 노드 만들기 및 컴포넌트 코드 실행)의 경우 동시성은 더욱 긴급한 업데이트가 이미 시작된 렌더링을 중단 할 수 있음을 의미합니다. -* 바운드 업데이트(예: 네트워크에서 코드나 데이터를 가져오는 것)의 경우 동시성은 모든 데이터가 도착하기 전에 React가 메모리에서 렌더링을 시작할 수 있으며 빈 로딩 상태가 표시되는 것을 건너뛰는 것을 의미합니다. +중요한 것은 React를 사용하는 방식이 똑같다는 것입니다. 컴포넌트, 프로퍼티즈 및 스테이트와 같은 개념은 근본적으로 동일한 방식으로 작동합니다. 화면을 업데이트하려면 스테이트를 설정합니다. -중요한 것은 React를 *사용*하는 방식이 똑같다는 것입니다. 컴포넌트, 소품 및 상태와 같은 개념은 근본적으로 동일한 방식으로 작동합니다. 화면을 업데이트하려면 상태를 설정합니다. +React는 휴리스틱을 사용하여 업데이트의 급함 정도를 결정하고 사용자가 모든 상호작용에 대해 원하는 사용자의 경험을 얻을 수 있도록 몇 줄의 코드를 조정하도록 합니다. -React는 휴리스틱을 사용하여 업데이트의 급함의 정도를 결정하고, 사용자가 모든 상호작용에 대해 원하는 사용자의 경험을 얻을 수 있도록 몇 줄의 코드를 조정하도록 합니다. -## 생산에 연구를 더하기 {#putting-research-into-production} +## 생산에 연구를 투입 {#putting-research-into-production} -Concurrent Mode 기능에 대한 공통 주제들이 있습니다. **이것의 목표는 사람-컴퓨터 간 상호작용에 대한 조사를 실제 UI에 통합시키는 것을 돕는 것입니다. ** +Concurrent Mode 기능에 대한 공통 주제들이 있습니다. **이것의 목표는 사람-컴퓨터 간 상호작용에 대한 조사를 실제 UI에 통합시키는 것을 돕는 것입니다.** 예를 들어, 조사에 따르면 화면 간 전환에서 중간 로딩 상태를 너무 많이 배치하는 것은 전환 자체를 더 *느리게* 느끼게 만든다고 합니다. 이것이 Concurrent Mode에서 고정된 "스케줄"에 새로운 로드 상태를 표시하여 부조화가 발생하는 것 또는 불필요하게 많이 업데이트되는 것을 피하고자 하는 이유입니다. -마찬가지로 조사 결과에 따르면, 호버나 텍스트 입력 같은 상호 작용은 아주 짧은 시간 안에 처리되어야 하는 반면에, 클릭이나 페이지 전환은 지루한 느낌 없이 조금 더 오래 기다릴 수 있습니다. Concurrent Mode 내부적으로 사용하는 다른 "우선순위"는 사람들의 인식에 대한 조사에서의 상호 작용에 대한 부분과 대략 일치합니다. +마찬가지로 조사 결과에 따르면, 호버나 텍스트 입력 같은 상호 작용은 아주 짧은 시간 안에 처리되어야 하지만, 클릭이나 페이지 전환은 지루한 느낌 없이 조금 더 오래 기다릴 수 있습니다. Concurrent Mode 내부적으로 사용하는 다른 "우선순위"는 사람들의 인식에 대한 조사에서의 상호 작용에 대한 부분과 대략 일치합니다. -UX(사용자 경험)에 중점을 둔 팀은 가끔 이러한 비슷한 문제들을 일회성 솔루션으로 해결하곤 합니다. 그러나, 그런 솔루션들은 오래 지속되기가 어렵고, 유지하기도 어렵습니다. Concurrent Mode에선, UI 조사 결과를 추상화시키고, 그것을 사용할 관용적인 방법을 제공하는 것입니다. UI 라이브러리로서 React는, 이것을 하기 위한 배치가 잘 되어 있습니다. - -## 다음 단계 {#next-steps} +UX(사용자 경험)에 중점을 둔 팀은 가끔 이러한 비슷한 문제들을 일회성 솔루션으로 해결하곤 합니다. 그러나, 그런 솔루션들은 오래 지속하기가 어렵고 유지하기도 어렵습니다. Concurrent Mode에선 UI 조사 결과를 추상화시키고 그것을 사용할 관용적인 방법을 제공하는 것입니다. UI 라이브러리로서 React는 이것을 하기 위한 배치가 잘 되어 있습니다. 이제 Concurrent Mode에 대해 모두 알게 되었습니다! -다음 페이지에서는 특정 주제에 대한 자세한 내용을 배웁니다: +다음 페이지에서는 특정 주제에 대한 자세한 내용을 배웁니다. -* [데이터를 가져오기 위한 서스펜스](/docs/concurrent-mode-suspense.html) 리액트 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다 -* [동시 UI 패턴](/docs/concurrent-mode-patterns.html) 동시모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다 -* [동시모드 채택](/docs/concurrent-mode-adoption.html) 프로젝트에서 동시모드를 어떻게 사용할 수 있는지를 설명합니다 -* [동시모드 API 참조](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다 +* [데이터를 가져오기 위한 서스펜스](/docs/concurrent-mode-suspense.html) 리액트 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. +* [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) 동시모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다. +* [Concurrent모드 채택](/docs/concurrent-mode-adoption.html) 프로젝트에서 동시모드를 어떻게 사용할 수 있는지를 설명합니다. +* [Concurrent모드 API 참조](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다. From b5e1e4c4bdfb7a7a9a5167408b9e38def04e81bd Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Tue, 19 Nov 2019 22:31:02 +0900 Subject: [PATCH 04/14] Modified concurrent-mode-intro.md(ver 3.0) --- content/docs/concurrent-mode-intro.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index dc95ff07c..3a03bc5c2 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -5,10 +5,9 @@ permalink: docs/concurrent-mode-intro.html next: concurrent-mode-suspense.html --- - >주의사항: > ->이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는] 실험적인 기능들에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 일부가 되기 전에 경고 없이 크게 변경될 수 있습니다. +>이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는] 실험적인 기능들**에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 일부가 되기 전에 경고 없이 크게 변경될 수 있습니다. > >이 문서는 얼리어답터들과 궁금해하시는 분들을 위해 제작된 문서입니다. React에 처음 접해본다면 이러한 기능들을 걱정하지 않아도 됩니다. 그 기능들을 바로 배울 필요는 없습니다. @@ -27,13 +26,13 @@ Concurrent모드는 React 앱이 빠른 반응속도를 유지하도록 하고 ## 차단 vs 인터럽트 렌더링 {#blocking-vs-interruptible-rendering} -** Concurrent 모드를 설명하기 위해서 버전 제어를 비유해서 설명할 것입니다. 팀에서 일하고 있다면 Git과 같은 버전 제어 시스템을 사용하며 브랜치로 작업할 것입니다 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다 +** Concurrent 모드를 설명하기 위해서 버전 제어를 비유해서 설명할 것입니다.** 팀에서 일하고 있다면 Git과 같은 버전 제어 시스템을 사용하며 브랜치로 작업할 것입니다 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다 버전 제어가 있기 전에는, 개발 작업의 흐름이 지금과는 매우 달랐습니다. 브랜치라는 개념이 없어서 몇몇 파일을 수정하려면 그 파일들을 수정 작업을 완료하기 전까지 작업하면 안 된다고 모든 사람에게 말해야 했습니다 심지어는 다른 사람과 동시에 일을 시작할 수도 없었습니다 즉, 문자그대로 이러한 제한사항들에 의해 *차단*되었습니다 이는 React를 포함한 UI 라이브러리들이 어떻게 오늘날 작용하는지를 설명해줍니다. 업데이트를 렌더링(새로운 DOM 노드 생성 및 컴포넌트 내에 있는 코드 실행하는 것을 포함해서)을 시작하면 이 일은 방해받지 않습니다. 이러한 접근을 "차단 렌더링"이라고 합니다 -Concurrent 모드에서는, 렌더링은 차단되지 않으나 인터럽트는 가능합니다. 이는 사용자의 경험을 증가시켜주며 또한 이전에 사용할 수 없었던 기능들을 사용할 수 있도록 만들어줍니다. 다음[https://reactjs.org/docs/concurrent-mode-suspense.html] 챕터[https://reactjs.org/docs/concurrent-mode-patterns.html]에서 구체적인 예시를 보기 전에, 새로운 기능들의 높은 수준의 개요를 해보려고 합니다. +Concurrent 모드에서는, 렌더링은 차단되지 않으나 인터럽트는 가능합니다. 이는 사용자의 경험을 증가시켜주며 또한 이전에 사용할 수 없었던 기능들을 사용할 수 있도록 만들어줍니다. [다음](https://reactjs.org/docs/concurrent-mode-suspense.html) [챕터](https://reactjs.org/docs/concurrent-mode-patterns.html)에서 구체적인 예시를 살펴보기 전에, 새로운 기능들의 높은 수준의 개요를 해보려고 합니다. ###인터럽트 가능한 렌더링 {#interruptible-rendering} @@ -43,7 +42,7 @@ Concurrent 모드에서는, 렌더링은 차단되지 않으나 인터럽트는 버벅거림의 이유는 간단합니다: 렌더링이 시작되면 중간에 중단될 수 없기 때문입니다. 그래서 그 브라우저는 텍스트 입력을 키를 누르는 즉시 업데이트할 수 없습니다. 벤치마크에서 UI 라이브러리( 예를 들어 React)가 아무리 잘 보일지라도, 차단 렌더링을 사용하고 컴포넌트의 일정량 작업을 하면 항상 버벅거림을 초래할 것입니다. 그리고 종종 이에 대한 쉬운 해결책이 없습니다. -**Concurrent 모드는 렌더링을 인터럽트 가능하도록 만듦으로써 근본적인 문제를 수정합니다. 이러한 사실은 사용자가 다른 키를 누를 때, React는 브라우저에 텍스트 입력을 업데이트하는 것을 차단할 필요가 없음을 의미합니다. 대신에, React는 브라우저가 입력에 대한 업데이트를 paint하고 *메모리 내에* 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다. 렌더링이 끝나면 React는 DOM을 업데이트하고 변경 사항들이 화면에 반영합니다. +**Concurrent 모드는 렌더링을 인터럽트 가능하도록 만듦으로써 근본적인 문제를 수정합니다.** 이러한 사실은 사용자가 다른 키를 누를 때, React는 브라우저에 텍스트 입력을 업데이트하는 것을 차단할 필요가 없음을 의미합니다. 대신에, React는 브라우저가 입력에 대한 업데이트를 paint하고 *메모리 내에* 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다. 렌더링이 끝나면 React는 DOM을 업데이트하고 변경 사항들이 화면에 반영합니다. 개념상으로, React가 지점별 모든 업데이트를 준비하는 것으로 생각할 수 있습니다. 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, Concurrent모드 내에 React는 더 중요한 일을 위해 진행 중인 업데이트를 중단할 수 있고 그리고서 이전 작업으로 돌아갈 수도 있습니다. 이 기술은 비디오 게임에서 [이중 버퍼링](https://wiki.osdev.org/Double_Buffering)을 떠오르게끔 할 수도 있습니다. From c290017984857624f351666a043b830826ff4cc2 Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Thu, 21 Nov 2019 10:51:00 +0900 Subject: [PATCH 05/14] Modifed concurrent-mode-intro.md(ver 4.0) --- content/docs/concurrent-mode-intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 3a03bc5c2..0d2aa0fb8 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -1,6 +1,6 @@ --- id: concurrent-mode-intro -title: Concurrent모드 소개(실험적) +title: Concurrent모드 소개 (실험적) permalink: docs/concurrent-mode-intro.html next: concurrent-mode-suspense.html --- @@ -26,7 +26,7 @@ Concurrent모드는 React 앱이 빠른 반응속도를 유지하도록 하고 ## 차단 vs 인터럽트 렌더링 {#blocking-vs-interruptible-rendering} -** Concurrent 모드를 설명하기 위해서 버전 제어를 비유해서 설명할 것입니다.** 팀에서 일하고 있다면 Git과 같은 버전 제어 시스템을 사용하며 브랜치로 작업할 것입니다 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다 +** Concurrent 모드를 설명하기 위해서 버전 제어를 비유해서 설명할 것입니다** 팀에서 일하고 있다면 Git과 같은 버전 제어 시스템을 사용하며 브랜치로 작업할 것입니다 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다 버전 제어가 있기 전에는, 개발 작업의 흐름이 지금과는 매우 달랐습니다. 브랜치라는 개념이 없어서 몇몇 파일을 수정하려면 그 파일들을 수정 작업을 완료하기 전까지 작업하면 안 된다고 모든 사람에게 말해야 했습니다 심지어는 다른 사람과 동시에 일을 시작할 수도 없었습니다 즉, 문자그대로 이러한 제한사항들에 의해 *차단*되었습니다 From 1c19d9e077364813bf01181e344a6589da7978fc Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Thu, 21 Nov 2019 13:43:45 +0900 Subject: [PATCH 06/14] Modified concurrent-mode-intro.md --- content/docs/concurrent-mode-intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 0d2aa0fb8..4efa9908c 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -26,7 +26,7 @@ Concurrent모드는 React 앱이 빠른 반응속도를 유지하도록 하고 ## 차단 vs 인터럽트 렌더링 {#blocking-vs-interruptible-rendering} -** Concurrent 모드를 설명하기 위해서 버전 제어를 비유해서 설명할 것입니다** 팀에서 일하고 있다면 Git과 같은 버전 제어 시스템을 사용하며 브랜치로 작업할 것입니다 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다 +**Concurrent 모드를 설명하기 위해서 버전 제어를 비유해서 설명할 것입니다** 팀에서 일하고 있다면 Git과 같은 버전 제어 시스템을 사용하며 브랜치로 작업할 것입니다 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다 버전 제어가 있기 전에는, 개발 작업의 흐름이 지금과는 매우 달랐습니다. 브랜치라는 개념이 없어서 몇몇 파일을 수정하려면 그 파일들을 수정 작업을 완료하기 전까지 작업하면 안 된다고 모든 사람에게 말해야 했습니다 심지어는 다른 사람과 동시에 일을 시작할 수도 없었습니다 즉, 문자그대로 이러한 제한사항들에 의해 *차단*되었습니다 @@ -42,7 +42,7 @@ Concurrent 모드에서는, 렌더링은 차단되지 않으나 인터럽트는 버벅거림의 이유는 간단합니다: 렌더링이 시작되면 중간에 중단될 수 없기 때문입니다. 그래서 그 브라우저는 텍스트 입력을 키를 누르는 즉시 업데이트할 수 없습니다. 벤치마크에서 UI 라이브러리( 예를 들어 React)가 아무리 잘 보일지라도, 차단 렌더링을 사용하고 컴포넌트의 일정량 작업을 하면 항상 버벅거림을 초래할 것입니다. 그리고 종종 이에 대한 쉬운 해결책이 없습니다. -**Concurrent 모드는 렌더링을 인터럽트 가능하도록 만듦으로써 근본적인 문제를 수정합니다.** 이러한 사실은 사용자가 다른 키를 누를 때, React는 브라우저에 텍스트 입력을 업데이트하는 것을 차단할 필요가 없음을 의미합니다. 대신에, React는 브라우저가 입력에 대한 업데이트를 paint하고 *메모리 내에* 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다. 렌더링이 끝나면 React는 DOM을 업데이트하고 변경 사항들이 화면에 반영합니다. +**Concurrent 모드는 렌더링을 인터럽트 가능하도록 만듦으로써 근본적인 문제를 수정합니다** 이러한 사실은 사용자가 다른 키를 누를 때, React는 브라우저에 텍스트 입력을 업데이트하는 것을 차단할 필요가 없음을 의미합니다. 대신에, React는 브라우저가 입력에 대한 업데이트를 paint하고 *메모리 내에* 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다. 렌더링이 끝나면 React는 DOM을 업데이트하고 변경 사항들이 화면에 반영합니다. 개념상으로, React가 지점별 모든 업데이트를 준비하는 것으로 생각할 수 있습니다. 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, Concurrent모드 내에 React는 더 중요한 일을 위해 진행 중인 업데이트를 중단할 수 있고 그리고서 이전 작업으로 돌아갈 수도 있습니다. 이 기술은 비디오 게임에서 [이중 버퍼링](https://wiki.osdev.org/Double_Buffering)을 떠오르게끔 할 수도 있습니다. From 9dae41a00482554baf73980520d5c81cf63faa2e Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Fri, 22 Nov 2019 12:53:32 +0900 Subject: [PATCH 07/14] Modifed concurrent-mode-intro.md (ver 6.0) --- content/docs/concurrent-mode-intro.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 4efa9908c..053072ded 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -1,6 +1,6 @@ --- id: concurrent-mode-intro -title: Concurrent모드 소개 (실험적) +title: Concurrent모드 소개 (실험 단계) permalink: docs/concurrent-mode-intro.html next: concurrent-mode-suspense.html --- @@ -13,10 +13,10 @@ next: concurrent-mode-suspense.html 이 페이지는 Concurrent 모드의 이론적인 개요를 제시합니다 **더 실용적인 설명을 위해서는 다음 섹션들을 참고하세요** -* [데이터를 가져오기 위한 서스펜스](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. +* [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. * [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다. -* [Concurrent 모드 채택](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드를 어떻게 사용할 수 있는지를 설명합니다. -* [Concurrent 모드 API reference](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다. +* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드를 어떻게 사용할 수 있는지를 설명합니다. +* [Concurrent 모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다. ## Concurrent 모드란? {#what-is-concurrent-mode} @@ -70,7 +70,7 @@ React는 휴리스틱을 사용하여 업데이트의 급함 정도를 결정하 ## 생산에 연구를 투입 {#putting-research-into-production} -Concurrent Mode 기능에 대한 공통 주제들이 있습니다. **이것의 목표는 사람-컴퓨터 간 상호작용에 대한 조사를 실제 UI에 통합시키는 것을 돕는 것입니다.** +Concurrent 모드 기능에 대한 공통 주제들이 있습니다. **이것의 목표는 사람-컴퓨터 간 상호작용에 대한 조사를 실제 UI에 통합시키는 것을 돕는 것입니다.** 예를 들어, 조사에 따르면 화면 간 전환에서 중간 로딩 상태를 너무 많이 배치하는 것은 전환 자체를 더 *느리게* 느끼게 만든다고 합니다. 이것이 Concurrent Mode에서 고정된 "스케줄"에 새로운 로드 상태를 표시하여 부조화가 발생하는 것 또는 불필요하게 많이 업데이트되는 것을 피하고자 하는 이유입니다. @@ -82,7 +82,7 @@ UX(사용자 경험)에 중점을 둔 팀은 가끔 이러한 비슷한 문제 다음 페이지에서는 특정 주제에 대한 자세한 내용을 배웁니다. -* [데이터를 가져오기 위한 서스펜스](/docs/concurrent-mode-suspense.html) 리액트 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. +* [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) 리액트 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. * [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) 동시모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다. -* [Concurrent모드 채택](/docs/concurrent-mode-adoption.html) 프로젝트에서 동시모드를 어떻게 사용할 수 있는지를 설명합니다. -* [Concurrent모드 API 참조](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다. +* [Concurrent모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 동시모드를 어떻게 사용할 수 있는지를 설명합니다. +* [Concurrent모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다. From 41945da738ab35bd4c6e515436f12fa00ed95065 Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Fri, 22 Nov 2019 13:08:15 +0900 Subject: [PATCH 08/14] Modified concurrent-mode-intro.md (ver 7.0) --- content/docs/concurrent-mode-intro.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 053072ded..326375bdc 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -7,15 +7,15 @@ next: concurrent-mode-suspense.html >주의사항: > ->이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는] 실험적인 기능들**에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 일부가 되기 전에 경고 없이 크게 변경될 수 있습니다. +>이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는](/docs/concurrent-mode-adoption.html) 실험적인 기능들**에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 일부가 되기 전에 경고 없이 크게 변경될 수 있습니다. > ->이 문서는 얼리어답터들과 궁금해하시는 분들을 위해 제작된 문서입니다. React에 처음 접해본다면 이러한 기능들을 걱정하지 않아도 됩니다. 그 기능들을 바로 배울 필요는 없습니다. +>이 문서는 얼리어답터들과 새로운 기능을 궁금해하시는 분들을 위해 작성된 문서입니다. React에 처음 접해본다면 이러한 기능들을 걱정하지 않아도 됩니다. 그 기능들을 바로 배울 필요는 없습니다. 이 페이지는 Concurrent 모드의 이론적인 개요를 제시합니다 **더 실용적인 설명을 위해서는 다음 섹션들을 참고하세요** * [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. * [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다. -* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드를 어떻게 사용할 수 있는지를 설명합니다. +* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프ㅌ로젝트에서 Concurrent 모드를 어떻게 사용할 수 있는지를 설명합니다. * [Concurrent 모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다. ## Concurrent 모드란? {#what-is-concurrent-mode} From 2097b19a07c693030f4b9a001ae1a5c5ea536fb1 Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Fri, 22 Nov 2019 13:10:55 +0900 Subject: [PATCH 09/14] Modified concurrent-mode-intro.md (ver 8.0) --- content/docs/concurrent-mode-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 326375bdc..6ff6a2302 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -15,7 +15,7 @@ next: concurrent-mode-suspense.html * [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. * [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다. -* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프ㅌ로젝트에서 Concurrent 모드를 어떻게 사용할 수 있는지를 설명합니다. +* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드를 어떻게 사용할 수 있는지를 설명합니다. * [Concurrent 모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다. ## Concurrent 모드란? {#what-is-concurrent-mode} From c77162e93978b3a08231d6df59be6c3a71aab7ac Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Fri, 22 Nov 2019 16:51:52 +0900 Subject: [PATCH 10/14] Modified concurrent-mode-intro.md (ver 9.0) --- content/docs/concurrent-mode-intro.md | 73 ++++++++++++++------------- 1 file changed, 37 insertions(+), 36 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 6ff6a2302..7174731be 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -5,84 +5,85 @@ permalink: docs/concurrent-mode-intro.html next: concurrent-mode-suspense.html --- ->주의사항: +>주의사항 > ->이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는](/docs/concurrent-mode-adoption.html) 실험적인 기능들**에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 일부가 되기 전에 경고 없이 크게 변경될 수 있습니다. +>이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는](/docs/concurrent-mode-adoption.html) 실험적인 기능들**에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 포함되기 전에 경고 없이 크게 변경될 수 있습니다. > >이 문서는 얼리어답터들과 새로운 기능을 궁금해하시는 분들을 위해 작성된 문서입니다. React에 처음 접해본다면 이러한 기능들을 걱정하지 않아도 됩니다. 그 기능들을 바로 배울 필요는 없습니다. -이 페이지는 Concurrent 모드의 이론적인 개요를 제시합니다 **더 실용적인 설명을 위해서는 다음 섹션들을 참고하세요** +이 페이지는 Concurrent 모드의 이론적인 개요를 설명합니다. **더 실용적인 설명을 위해서는 다음 섹션들을 참고하세요** * [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. -* [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다. -* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드를 어떻게 사용할 수 있는지를 설명합니다. -* [Concurrent 모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다. +* [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 Suspense로 만들어진 UI 패턴들을 설명합니다. +* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드 사용방법을 설명합니다. +* [Concurrent 모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새로운 API 문서입니다. ## Concurrent 모드란? {#what-is-concurrent-mode} -Concurrent모드는 React 앱이 빠른 반응속도를 유지하도록 하고 사용자의 장치 기능 및 네트워크 속도에 적절하게 맞추도록 돕는 새로운 기능들의 집합체입니다 +Concurrent모드는 React 앱이 빠른 반응속도를 유지하도록 하고 사용자의 장치 기능 및 네트워크 속도에 적절하게 맞추도록 돕는 새로운 기능들의 집합체입니다. -이 기능들은 여전히 실험적이며 수정되어야 합니다. 아직 안정된 React 배포판에 일부가 된 것은 아니지만, 실험 배포판에서 그 기능들을 시도해볼 수는 있습니다 +이 기능들은 여전히 실험적이며 변경될 수 있습니다. 아직 안정된 React 배포판에 포함되지 않았지만, 실험 배포판에서 그 기능들을 시도해볼 수는 있습니다. ## 차단 vs 인터럽트 렌더링 {#blocking-vs-interruptible-rendering} -**Concurrent 모드를 설명하기 위해서 버전 제어를 비유해서 설명할 것입니다** 팀에서 일하고 있다면 Git과 같은 버전 제어 시스템을 사용하며 브랜치로 작업할 것입니다 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다 +**Concurrent 모드를 설명하기 위해서 버전 관리를 예를 들어 설명할 것입니다** 팀에서 일하고 있다면 Git과 같은 버전 관리 시스템을 사용하며 브랜치로 작업할 것입니다. 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다. -버전 제어가 있기 전에는, 개발 작업의 흐름이 지금과는 매우 달랐습니다. 브랜치라는 개념이 없어서 몇몇 파일을 수정하려면 그 파일들을 수정 작업을 완료하기 전까지 작업하면 안 된다고 모든 사람에게 말해야 했습니다 심지어는 다른 사람과 동시에 일을 시작할 수도 없었습니다 즉, 문자그대로 이러한 제한사항들에 의해 *차단*되었습니다 +버전 관리가 있기 전에는, 개발 작업의 흐름이 지금과는 많이 달랐습니다. 브랜치라는 개념이 없어서 몇몇 파일을 수정하려면 그 파일들을 수정 작업을 완료하기 전까지 작업하면 안 된다고 모든 사람에게 말해야 했습니다. 심지어는 다른 사람과 동시에 일을 시작할 수도 없었습니다 즉, 문자그대로 이러한 제한사항들에 의해 *차단*되었습니다. -이는 React를 포함한 UI 라이브러리들이 어떻게 오늘날 작용하는지를 설명해줍니다. 업데이트를 렌더링(새로운 DOM 노드 생성 및 컴포넌트 내에 있는 코드 실행하는 것을 포함해서)을 시작하면 이 일은 방해받지 않습니다. 이러한 접근을 "차단 렌더링"이라고 합니다 +이는 React를 포함한 UI 라이브러리들이 어떻게 오늘날 작용하는지를 설명해줍니다. 업데이트 렌더링(새로운 DOM 노드 생성 및 컴포넌트 내에 있는 코드 실행하는 것을 포함해서)을 시작하면 이 일은 방해받지 않습니다. 이러한 접근을 "렌더링 차단"이라고 합니다. -Concurrent 모드에서는, 렌더링은 차단되지 않으나 인터럽트는 가능합니다. 이는 사용자의 경험을 증가시켜주며 또한 이전에 사용할 수 없었던 기능들을 사용할 수 있도록 만들어줍니다. [다음](https://reactjs.org/docs/concurrent-mode-suspense.html) [챕터](https://reactjs.org/docs/concurrent-mode-patterns.html)에서 구체적인 예시를 살펴보기 전에, 새로운 기능들의 높은 수준의 개요를 해보려고 합니다. +Concurrent 모드에서는, 렌더링은 차단되지 않으나 인터럽트는 가능합니다. 이는 사용자의 경험을 개선하며 또한 이전에 사용할 수 없었던 기능들을 사용할 수 있도록 만들어줍니다. [다음](https://reactjs.org/docs/concurrent-mode-suspense.html) [챕터](https://reactjs.org/docs/concurrent-mode-patterns.html)에서 구체적인 예시를 살펴보기 전에, 새로운 기능들의 높은 수준의 개요를 해보려고 합니다. ###인터럽트 가능한 렌더링 {#interruptible-rendering} -필터링 가능한 제품 목록을 생각해보세요. 목록 필터에 입력하고 모든 키를 누를 때마다 버벅거림을 느낀 적이 있습니까? 제품 목록을 업데이트하는 몇몇 작업은 불가피할 수 있습니다. (예를 들어, 새로운 DOM 노드를 만들거나 레이아웃을 수행하는 브라우저를 만드는 작업) 그러면, *언제* *어떻게* 이런 비중 있는 작업을 수행할까요? +필터링 가능한 제품 목록을 생각해보세요. 목록 필터에 입력하고 모든 키를 누를 때마다 버벅거림을 느낀 적이 있나요? 제품 목록을 업데이트하는 몇몇 작업은 불가피할 수 있습니다. (예를 들어, 새로운 DOM 노드를 만들거나 레이아웃을 수행하는 브라우저를 만드는 작업) 그러면, *언제* *어떻게* 이런 비중 있는 작업을 수행할까요? -버벅거림을 해결하는 한 가지 방법은 입력을 디바운싱해주는 것입니다 디바운싱하면, 사용자가 타이핑을 멈추고 나서만 목록을 업데이트합니다. 하지만, 타이핑하고 있을 때 UI가 업데이트하지 않는 사실이 실망스러울 수 있습니다. 이에 대한 대안으로, 입력을 “스로틀”하고 목록을 특정 최대 빈도수로 업데이트 할 수 있습니다. 그러나 저전력 장치에서는 여전히 버벅거릴 것입니다. 디 바운싱 및 쓰로틀링은 둘 다 최적이 아닌 사용자 환경을 만듭니다. +버벅거림을 해결하는 한 가지 방법은 입력을 "디바운싱"해주는 것입니다 디바운싱하면, 사용자가 타이핑을 멈추고 나서만 목록을 업데이트합니다. 하지만, 타이핑하고 있을 때 UI가 업데이트하지 않는 사실이 실망스러울 수 있습니다. 이에 대한 대안으로, 입력을 “스로틀”하고 목록을 특정 최대 빈도수로 업데이트 할 수 있습니다. 그러나 저전력 장치에서는 여전히 버벅거릴 것입니다. 디 바운싱 및 쓰로틀링은 둘 다 최적이 아닌 사용자 환경을 만듭니다. -버벅거림의 이유는 간단합니다: 렌더링이 시작되면 중간에 중단될 수 없기 때문입니다. 그래서 그 브라우저는 텍스트 입력을 키를 누르는 즉시 업데이트할 수 없습니다. 벤치마크에서 UI 라이브러리( 예를 들어 React)가 아무리 잘 보일지라도, 차단 렌더링을 사용하고 컴포넌트의 일정량 작업을 하면 항상 버벅거림을 초래할 것입니다. 그리고 종종 이에 대한 쉬운 해결책이 없습니다. +버벅거리는 이유는 간단합니다 렌더링이 시작되면 중간에 중단될 수 없기 때문입니다. 그래서 그 브라우저는 텍스트 입력을 키를 누르는 즉시 업데이트할 수 없습니다. 벤치마크에서 UI 라이브러리(예를 들어 React)가 아무리 잘 보일지라도, 차단 렌더링을 사용하고 컴포넌트의 일정량 작업을 하면 항상 버벅거림을 초래할 것입니다. 그리고 종종, 이에 대한 쉬운 해결책을 찾기 어렵습니다. -**Concurrent 모드는 렌더링을 인터럽트 가능하도록 만듦으로써 근본적인 문제를 수정합니다** 이러한 사실은 사용자가 다른 키를 누를 때, React는 브라우저에 텍스트 입력을 업데이트하는 것을 차단할 필요가 없음을 의미합니다. 대신에, React는 브라우저가 입력에 대한 업데이트를 paint하고 *메모리 내에* 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다. 렌더링이 끝나면 React는 DOM을 업데이트하고 변경 사항들이 화면에 반영합니다. +**Concurrent 모드는 렌더링을 인터럽트 가능하도록 만듦으로써 근본적인 문제를 수정합니다** 이러한 사실은 사용자가 다른 키를 누를 때, React는 브라우저에 텍스트 입력을 업데이트하는 것을 차단할 필요가 없음을 의미합니다. 대신에, React는 브라우저가 입력에 대한 업데이트를 paint하고 *메모리 내에* 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다. 렌더링이 끝나면 React는 DOM을 업데이트하고 변경 사항들을 화면에 반영합니다. -개념상으로, React가 지점별 모든 업데이트를 준비하는 것으로 생각할 수 있습니다. 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, Concurrent모드 내에 React는 더 중요한 일을 위해 진행 중인 업데이트를 중단할 수 있고 그리고서 이전 작업으로 돌아갈 수도 있습니다. 이 기술은 비디오 게임에서 [이중 버퍼링](https://wiki.osdev.org/Double_Buffering)을 떠오르게끔 할 수도 있습니다. +개념상으로, React가 "브랜치에서" 모든 업데이트를 준비하는 것으로 생각할 수 있습니다. 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, Concurrent모드 내에 React는 더 중요한 일을 위해 진행 중인 업데이트를 중단할 수 있고 그리고서 이전 작업으로 돌아갈 수도 있습니다. 이 기술은 비디오 게임에서 [이중 버퍼링](https://wiki.osdev.org/Double_Buffering)을 떠오르게끔 할 수도 있습니다. -Concurrent모드 기술은 UI에서 디바운싱과 스로틀링의 필요성을 줄입니다 렌더링은 중단이 가능하기 때문에 버벅거림을 피하고자 일부러 작업을 지연시킬 필요가 없습니다. React는 렌더링을 즉시 시작할 수 있지만, 앱의 즉각적인 반응성이 요구될 때는 이 작업을 중단할 수도 있습니다. +Concurrent모드 기술은 UI에서 디바운싱과 스로틀링의 필요성을 줄입니다 렌더링은 중단이 가능하기 때문에 버벅거림을 피하고자 일부러 작업을 지연시킬 필요가 없습니다. React는 렌더링을 즉시 시작할 수 있지만, 앱에 즉각적인 반응성이 요구될 때는 이 작업을 중단할 수도 있습니다. ### 의도적인 로딩 시퀀스 {#intentional-loading-sequences} -Concurrent 모드는 브랜치에서 React 작업과 같다고 전에 말했습니다. 브랜치는 단기적인 수정을 할 때뿐만 아니라 장기적인 기능에도 유용합니다. 가끔 기능에 대해 작업을 할 수도 있습니다. 하지만 마스터로 병합할 수 있는 적합한 스테이트가 되기까지 몇 주가 걸릴 수 있습니다. 버전 관리 비유의 측면은 렌더링에도 적용됩니다. +Concurrent 모드는 "브랜치에서" 하는 React 작업과 같다고 전에 말했습니다. 브랜치는 단기적인 수정을 할 때뿐만 아니라 장기적인 실행 기능에도 유용합니다. 때로는 기능에 대해 작업을 할 수도 있습니다. 하지만 마스터로 병합할 수 있는 "적합한 state"가 되기까지 몇 주가 걸릴 수 있습니다. 버전 관리의 이러한 측면은 렌더링에도 적용됩니다. -한번 앱에서 두 화면 사이를 탐색한다고 가정해보겠습니다. 때로는 새 화면에서 사용자에게 좋은 로딩 스테이트를 보여주기 위해 충분한 코드와 데이터를 불러오지 못 할 수 있습니다. 빈 화면이나 큰 스피너로 전환하는 것은 어려운 경험이 될 수 있습니다. 하지만 필요한 코드와 데이터를 가져오는 데 너무 오래 걸리지 않는 것 또한 흔한 일입니다. **React가 기존 화면에서 조금 더 오래 머물 수 있고 새 화면을 보여주기 전에 안 좋은 로딩 스테이트를 건너뛸 수 있게 해준다면 더 좋지 않겠습니까?** +한번 앱에서 두 화면 사이를 탐색한다고 가정해보겠습니다. 경우에 따라서, 새 화면에서 사용자에게 "충분히 좋은" 로딩 state를 보여주기 위해 필요한 코드와 데이터를 불러오지 못 할 수 있습니다. 빈 화면이나 큰 스피너로 전환하는 것은 어려운 일이 될 수 있지만 일반적으로 필요한 코드와 데이터를 가져오는 데에 그렇게 많은 시간이 소요되지않습니다. **React가 기존 화면에서 조금 더 오래 유지할 수 있고 새 화면을 보여주기 전에 "안 좋은" 로딩 state를 "건너뛸 수" 있다면 더 좋지 않을까요?** -오늘날 이것이 가능하긴 하지만 조정하기는 어려울 수 있습니다. Concurrent 모드에서는 이 기능이 내장되어 있습니다. React는 먼저 메모리에서 새로운 화면을 준비하기 시작하는데 또는 우리의 비유처럼 다른 브랜치에서 시작합니다. 따라서 React는 더 많은 콘텐츠를 불러올 수 있도록 DOM을 업데이트하기 전에 기다릴 수 있습니다. Concurrent 모드에서 React에 인라인 표시기와 함께 완전히 상호작용하여 이전 화면을 계속 표시하도록 지시할 수 있습니다. 그리고 새로운 화면이 준비되면 React는 그곳으로 데려갈 수 있습니다. +오늘날 이것이 가능하긴 하지만 조정하기는 어려울 수 있습니다. Concurrent 모드에서는 이 기능이 내장되어 있습니다. React는 먼저 메모리, 비유하자면 "다른 브랜치", 에서 새로운 화면을 준비하기 시작합니다. 그래서 React는 더 많은 콘텐츠를 불러올 수 있도록 DOM을 업데이트하기 전에 기다릴 수 있습니다. Concurrent 모드에서는 React가 인라인 표시기로 완벽하게 상호작용하는 이전 화면을 계속 표시하도록 지시할 수 있습니다. ### 동시성 {#concurrency} -위의 두 가지 예시를 살펴보고 Concurrent 모드가 어떻게 통합되는지 살펴보겠습니다. **Concurrent 모드에서 React는** 여러 팀 구성원이 독립적으로 작업할 수 있도록 하는 브랜치처럼 **여러 스테이트 업데이트를 *동시에* 수행 할 수 있습니다**. +위의 두 가지 예시를 살펴보고 Concurrent 모드가 어떻게 통합되는지 살펴보겠습니다. **Concurrent 모드에서 React는 여러 작업을 *동시에*, 다른 팀원들이 각자 작업을 할 수 있는 브랜치처럼, 진행할 수 있습니다** -* CPU 바운드 업데이트(예를 들어 DOM 노드 만들기 및 컴포넌트 코드 실행)의 경우 Concurrency는 더욱 긴급한 업데이트가 이미 시작된 렌더링을 중단 할 수 있음을 의미합니다. -* IO 바운드 업데이트(예를 들어 네트워크에서 코드나 데이터를 가져오는 것)의 경우 Concurrency는 모든 데이터가 도착하기 전에 React가 메모리에서 렌더링을 시작할 수 있으며 빈 로딩 스테이트가 표시되는 것을 건너뜀을 의미합니다. +* CPU 바운드 업데이트(예를 들어 DOM 노드 만들기 및 컴포넌트 코드 실행)의 경우 Concurrency는 더욱 긴급한 업데이트가 이미 시작한 렌더링을 "중단" 할 수 있음을 의미합니다. +* IO 바운드 업데이트(예를 들어 네트워크에서 코드나 데이터를 가져오는 것)의 경우 Concurrency는 모든 데이터가 도달하기 전에 React가 메모리에서 렌더링을 시작할 수 있으며 빈 로딩 state표시를 무시할 수 있음을 의미합니다. -중요한 것은 React를 사용하는 방식이 똑같다는 것입니다. 컴포넌트, 프로퍼티즈 및 스테이트와 같은 개념은 근본적으로 동일한 방식으로 작동합니다. 화면을 업데이트하려면 스테이트를 설정합니다. - -React는 휴리스틱을 사용하여 업데이트의 급함 정도를 결정하고 사용자가 모든 상호작용에 대해 원하는 사용자의 경험을 얻을 수 있도록 몇 줄의 코드를 조정하도록 합니다. +중요한 것은 React를 사용하는 *방식*이 똑같다는 것입니다. 컴포넌트, props 및 state와 같은 개념은 근본적으로 동일한 방식으로 작동합니다. 화면을 업데이트하려면 state를 설정합니다. +React는 휴리스틱을 사용하여 업데이트의 "급함" 정도를 결정하고 몇 줄의 코드를 수정해서 사용자가 모든 상호작용에 대해 원하는 사용자의 경험을 얻을 수 있도록 합니다.. ## 생산에 연구를 투입 {#putting-research-into-production} -Concurrent 모드 기능에 대한 공통 주제들이 있습니다. **이것의 목표는 사람-컴퓨터 간 상호작용에 대한 조사를 실제 UI에 통합시키는 것을 돕는 것입니다.** +Concurrent 모드 기능에 대한 공통 주제들이 있습니다. **이 주제들의 목표는 사람-컴퓨터 간 상호작용에 대한 연구 결과가 실제 UI와 통합되도록 돕는 것입니다.** + +예를 들어, 조사에 따르면 화면 간 전환에서 중간 로딩 state를 너무 많이 표시하면 전환이 더 *느리게* 느껴진다고 합니다. 이것이 Concurrent 모드에서 고정된 "스케줄"에 새로운 로드 state를 표시하여 부조화가 발생하는 것 또는 불필요하게 많이 업데이트되는 것을 피하고자 하는 이유입니다. -예를 들어, 조사에 따르면 화면 간 전환에서 중간 로딩 상태를 너무 많이 배치하는 것은 전환 자체를 더 *느리게* 느끼게 만든다고 합니다. 이것이 Concurrent Mode에서 고정된 "스케줄"에 새로운 로드 상태를 표시하여 부조화가 발생하는 것 또는 불필요하게 많이 업데이트되는 것을 피하고자 하는 이유입니다. +마찬가지로 조사 결과에 따르면, 호버나 텍스트 입력 같은 상호 작용은 아주 짧은 시간 안에 처리되어야 하지만, 클릭이나 페이지 전환은 조금 더 오래 걸린다고 해도 지루한 느낌을 주지않는다고 합니다. Concurrent 모드 내부적으로 사용하는 다른 "우선순위"는 사람들의 인식에 대한 조사에서의 상호 작용에 대한 부분과 대략적으로 일치합니다. -마찬가지로 조사 결과에 따르면, 호버나 텍스트 입력 같은 상호 작용은 아주 짧은 시간 안에 처리되어야 하지만, 클릭이나 페이지 전환은 지루한 느낌 없이 조금 더 오래 기다릴 수 있습니다. Concurrent Mode 내부적으로 사용하는 다른 "우선순위"는 사람들의 인식에 대한 조사에서의 상호 작용에 대한 부분과 대략 일치합니다. +UX(사용자 경험)에 중점을 둔 팀은 가끔 이러한 비슷한 문제들을 일회성 솔루션으로 해결하곤 합니다. 그러나, 그런 솔루션들은 오래 지속하기가 어렵고 유지하기도 어렵습니다. Concurrent 모드를 통한 목적은 UI 조사 결과를 추상화시키고 그것을 사용할 관용적인 방법을 제공하는 것입니다. UI 라이브러리로서, React는 이러한 일을 할 수 있습니다. -UX(사용자 경험)에 중점을 둔 팀은 가끔 이러한 비슷한 문제들을 일회성 솔루션으로 해결하곤 합니다. 그러나, 그런 솔루션들은 오래 지속하기가 어렵고 유지하기도 어렵습니다. Concurrent Mode에선 UI 조사 결과를 추상화시키고 그것을 사용할 관용적인 방법을 제공하는 것입니다. UI 라이브러리로서 React는 이것을 하기 위한 배치가 잘 되어 있습니다. +## 다음 단계 {#next-steps} -이제 Concurrent Mode에 대해 모두 알게 되었습니다! +이제 Concurrent 모드에 대해 모두 알게 되었습니다! 다음 페이지에서는 특정 주제에 대한 자세한 내용을 배웁니다. -* [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) 리액트 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. -* [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) 동시모드와 서스펜스로 만들어진 UI 패턴들을 보여줍니다. -* [Concurrent모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 동시모드를 어떻게 사용할 수 있는지를 설명합니다. -* [Concurrent모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새 API들을 문서화합니다. +* [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. +* [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 Suspense로 만들어진 UI 패턴들을 설명합니다. +* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드 사용방법을 설명합니다. +* [Concurrent 모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새로운 API 문서입니다. From d530d4cd709b98340d44026f0fb4ba05793117da Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Sun, 24 Nov 2019 20:34:51 +0900 Subject: [PATCH 11/14] Resolving Conflict --- content/docs/concurrent-mode-intro.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 7174731be..41e12789d 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -5,6 +5,15 @@ permalink: docs/concurrent-mode-intro.html next: concurrent-mode-suspense.html --- + + +
+ >주의사항 > >이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는](/docs/concurrent-mode-adoption.html) 실험적인 기능들**에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 포함되기 전에 경고 없이 크게 변경될 수 있습니다. From 4009f4f6a33928a3b54a33256cfa7516de3e763c Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Sun, 24 Nov 2019 20:49:18 +0900 Subject: [PATCH 12/14] Resolving confliect(ver 2.0) --- content/docs/concurrent-mode-intro.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 41e12789d..6a2a477ce 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -18,7 +18,9 @@ next: concurrent-mode-suspense.html > >이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는](/docs/concurrent-mode-adoption.html) 실험적인 기능들**에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 포함되기 전에 경고 없이 크게 변경될 수 있습니다. > ->이 문서는 얼리어답터들과 새로운 기능을 궁금해하시는 분들을 위해 작성된 문서입니다. React에 처음 접해본다면 이러한 기능들을 걱정하지 않아도 됩니다. 그 기능들을 바로 배울 필요는 없습니다. +>이 문서는 얼리어답터들과 새로운 기능을 궁금해하시는 분들을 위해 작성된 문서입니다. **React에 처음 접해본다면 이러한 기능들을 걱정하지 않아도 됩니다**. 그 기능들을 바로 배울 필요는 없습니다. + +
이 페이지는 Concurrent 모드의 이론적인 개요를 설명합니다. **더 실용적인 설명을 위해서는 다음 섹션들을 참고하세요** From 26c3aae1b9d6a0d1ef49ac628d127ccdc4bacf75 Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 <55736449+Yohan-Kim2@users.noreply.github.com> Date: Sun, 24 Nov 2019 20:50:16 +0900 Subject: [PATCH 13/14] Delete concurrent-mode-intro.md --- content/docs/concurrent-mode-intro.md | 100 -------------------------- 1 file changed, 100 deletions(-) delete mode 100644 content/docs/concurrent-mode-intro.md diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md deleted file mode 100644 index 6a2a477ce..000000000 --- a/content/docs/concurrent-mode-intro.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -id: concurrent-mode-intro -title: Concurrent모드 소개 (실험 단계) -permalink: docs/concurrent-mode-intro.html -next: concurrent-mode-suspense.html ---- - - - -
- ->주의사항 -> ->이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는](/docs/concurrent-mode-adoption.html) 실험적인 기능들**에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 포함되기 전에 경고 없이 크게 변경될 수 있습니다. -> ->이 문서는 얼리어답터들과 새로운 기능을 궁금해하시는 분들을 위해 작성된 문서입니다. **React에 처음 접해본다면 이러한 기능들을 걱정하지 않아도 됩니다**. 그 기능들을 바로 배울 필요는 없습니다. - -
- -이 페이지는 Concurrent 모드의 이론적인 개요를 설명합니다. **더 실용적인 설명을 위해서는 다음 섹션들을 참고하세요** - -* [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. -* [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 Suspense로 만들어진 UI 패턴들을 설명합니다. -* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드 사용방법을 설명합니다. -* [Concurrent 모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새로운 API 문서입니다. - -## Concurrent 모드란? {#what-is-concurrent-mode} - -Concurrent모드는 React 앱이 빠른 반응속도를 유지하도록 하고 사용자의 장치 기능 및 네트워크 속도에 적절하게 맞추도록 돕는 새로운 기능들의 집합체입니다. - -이 기능들은 여전히 실험적이며 변경될 수 있습니다. 아직 안정된 React 배포판에 포함되지 않았지만, 실험 배포판에서 그 기능들을 시도해볼 수는 있습니다. - -## 차단 vs 인터럽트 렌더링 {#blocking-vs-interruptible-rendering} - -**Concurrent 모드를 설명하기 위해서 버전 관리를 예를 들어 설명할 것입니다** 팀에서 일하고 있다면 Git과 같은 버전 관리 시스템을 사용하며 브랜치로 작업할 것입니다. 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다. - -버전 관리가 있기 전에는, 개발 작업의 흐름이 지금과는 많이 달랐습니다. 브랜치라는 개념이 없어서 몇몇 파일을 수정하려면 그 파일들을 수정 작업을 완료하기 전까지 작업하면 안 된다고 모든 사람에게 말해야 했습니다. 심지어는 다른 사람과 동시에 일을 시작할 수도 없었습니다 즉, 문자그대로 이러한 제한사항들에 의해 *차단*되었습니다. - -이는 React를 포함한 UI 라이브러리들이 어떻게 오늘날 작용하는지를 설명해줍니다. 업데이트 렌더링(새로운 DOM 노드 생성 및 컴포넌트 내에 있는 코드 실행하는 것을 포함해서)을 시작하면 이 일은 방해받지 않습니다. 이러한 접근을 "렌더링 차단"이라고 합니다. - -Concurrent 모드에서는, 렌더링은 차단되지 않으나 인터럽트는 가능합니다. 이는 사용자의 경험을 개선하며 또한 이전에 사용할 수 없었던 기능들을 사용할 수 있도록 만들어줍니다. [다음](https://reactjs.org/docs/concurrent-mode-suspense.html) [챕터](https://reactjs.org/docs/concurrent-mode-patterns.html)에서 구체적인 예시를 살펴보기 전에, 새로운 기능들의 높은 수준의 개요를 해보려고 합니다. - -###인터럽트 가능한 렌더링 {#interruptible-rendering} - -필터링 가능한 제품 목록을 생각해보세요. 목록 필터에 입력하고 모든 키를 누를 때마다 버벅거림을 느낀 적이 있나요? 제품 목록을 업데이트하는 몇몇 작업은 불가피할 수 있습니다. (예를 들어, 새로운 DOM 노드를 만들거나 레이아웃을 수행하는 브라우저를 만드는 작업) 그러면, *언제* *어떻게* 이런 비중 있는 작업을 수행할까요? - -버벅거림을 해결하는 한 가지 방법은 입력을 "디바운싱"해주는 것입니다 디바운싱하면, 사용자가 타이핑을 멈추고 나서만 목록을 업데이트합니다. 하지만, 타이핑하고 있을 때 UI가 업데이트하지 않는 사실이 실망스러울 수 있습니다. 이에 대한 대안으로, 입력을 “스로틀”하고 목록을 특정 최대 빈도수로 업데이트 할 수 있습니다. 그러나 저전력 장치에서는 여전히 버벅거릴 것입니다. 디 바운싱 및 쓰로틀링은 둘 다 최적이 아닌 사용자 환경을 만듭니다. - -버벅거리는 이유는 간단합니다 렌더링이 시작되면 중간에 중단될 수 없기 때문입니다. 그래서 그 브라우저는 텍스트 입력을 키를 누르는 즉시 업데이트할 수 없습니다. 벤치마크에서 UI 라이브러리(예를 들어 React)가 아무리 잘 보일지라도, 차단 렌더링을 사용하고 컴포넌트의 일정량 작업을 하면 항상 버벅거림을 초래할 것입니다. 그리고 종종, 이에 대한 쉬운 해결책을 찾기 어렵습니다. - -**Concurrent 모드는 렌더링을 인터럽트 가능하도록 만듦으로써 근본적인 문제를 수정합니다** 이러한 사실은 사용자가 다른 키를 누를 때, React는 브라우저에 텍스트 입력을 업데이트하는 것을 차단할 필요가 없음을 의미합니다. 대신에, React는 브라우저가 입력에 대한 업데이트를 paint하고 *메모리 내에* 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다. 렌더링이 끝나면 React는 DOM을 업데이트하고 변경 사항들을 화면에 반영합니다. - -개념상으로, React가 "브랜치에서" 모든 업데이트를 준비하는 것으로 생각할 수 있습니다. 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, Concurrent모드 내에 React는 더 중요한 일을 위해 진행 중인 업데이트를 중단할 수 있고 그리고서 이전 작업으로 돌아갈 수도 있습니다. 이 기술은 비디오 게임에서 [이중 버퍼링](https://wiki.osdev.org/Double_Buffering)을 떠오르게끔 할 수도 있습니다. - -Concurrent모드 기술은 UI에서 디바운싱과 스로틀링의 필요성을 줄입니다 렌더링은 중단이 가능하기 때문에 버벅거림을 피하고자 일부러 작업을 지연시킬 필요가 없습니다. React는 렌더링을 즉시 시작할 수 있지만, 앱에 즉각적인 반응성이 요구될 때는 이 작업을 중단할 수도 있습니다. - -### 의도적인 로딩 시퀀스 {#intentional-loading-sequences} - -Concurrent 모드는 "브랜치에서" 하는 React 작업과 같다고 전에 말했습니다. 브랜치는 단기적인 수정을 할 때뿐만 아니라 장기적인 실행 기능에도 유용합니다. 때로는 기능에 대해 작업을 할 수도 있습니다. 하지만 마스터로 병합할 수 있는 "적합한 state"가 되기까지 몇 주가 걸릴 수 있습니다. 버전 관리의 이러한 측면은 렌더링에도 적용됩니다. - -한번 앱에서 두 화면 사이를 탐색한다고 가정해보겠습니다. 경우에 따라서, 새 화면에서 사용자에게 "충분히 좋은" 로딩 state를 보여주기 위해 필요한 코드와 데이터를 불러오지 못 할 수 있습니다. 빈 화면이나 큰 스피너로 전환하는 것은 어려운 일이 될 수 있지만 일반적으로 필요한 코드와 데이터를 가져오는 데에 그렇게 많은 시간이 소요되지않습니다. **React가 기존 화면에서 조금 더 오래 유지할 수 있고 새 화면을 보여주기 전에 "안 좋은" 로딩 state를 "건너뛸 수" 있다면 더 좋지 않을까요?** - -오늘날 이것이 가능하긴 하지만 조정하기는 어려울 수 있습니다. Concurrent 모드에서는 이 기능이 내장되어 있습니다. React는 먼저 메모리, 비유하자면 "다른 브랜치", 에서 새로운 화면을 준비하기 시작합니다. 그래서 React는 더 많은 콘텐츠를 불러올 수 있도록 DOM을 업데이트하기 전에 기다릴 수 있습니다. Concurrent 모드에서는 React가 인라인 표시기로 완벽하게 상호작용하는 이전 화면을 계속 표시하도록 지시할 수 있습니다. - -### 동시성 {#concurrency} - -위의 두 가지 예시를 살펴보고 Concurrent 모드가 어떻게 통합되는지 살펴보겠습니다. **Concurrent 모드에서 React는 여러 작업을 *동시에*, 다른 팀원들이 각자 작업을 할 수 있는 브랜치처럼, 진행할 수 있습니다** - -* CPU 바운드 업데이트(예를 들어 DOM 노드 만들기 및 컴포넌트 코드 실행)의 경우 Concurrency는 더욱 긴급한 업데이트가 이미 시작한 렌더링을 "중단" 할 수 있음을 의미합니다. -* IO 바운드 업데이트(예를 들어 네트워크에서 코드나 데이터를 가져오는 것)의 경우 Concurrency는 모든 데이터가 도달하기 전에 React가 메모리에서 렌더링을 시작할 수 있으며 빈 로딩 state표시를 무시할 수 있음을 의미합니다. - -중요한 것은 React를 사용하는 *방식*이 똑같다는 것입니다. 컴포넌트, props 및 state와 같은 개념은 근본적으로 동일한 방식으로 작동합니다. 화면을 업데이트하려면 state를 설정합니다. - -React는 휴리스틱을 사용하여 업데이트의 "급함" 정도를 결정하고 몇 줄의 코드를 수정해서 사용자가 모든 상호작용에 대해 원하는 사용자의 경험을 얻을 수 있도록 합니다.. - -## 생산에 연구를 투입 {#putting-research-into-production} - -Concurrent 모드 기능에 대한 공통 주제들이 있습니다. **이 주제들의 목표는 사람-컴퓨터 간 상호작용에 대한 연구 결과가 실제 UI와 통합되도록 돕는 것입니다.** - -예를 들어, 조사에 따르면 화면 간 전환에서 중간 로딩 state를 너무 많이 표시하면 전환이 더 *느리게* 느껴진다고 합니다. 이것이 Concurrent 모드에서 고정된 "스케줄"에 새로운 로드 state를 표시하여 부조화가 발생하는 것 또는 불필요하게 많이 업데이트되는 것을 피하고자 하는 이유입니다. - -마찬가지로 조사 결과에 따르면, 호버나 텍스트 입력 같은 상호 작용은 아주 짧은 시간 안에 처리되어야 하지만, 클릭이나 페이지 전환은 조금 더 오래 걸린다고 해도 지루한 느낌을 주지않는다고 합니다. Concurrent 모드 내부적으로 사용하는 다른 "우선순위"는 사람들의 인식에 대한 조사에서의 상호 작용에 대한 부분과 대략적으로 일치합니다. - -UX(사용자 경험)에 중점을 둔 팀은 가끔 이러한 비슷한 문제들을 일회성 솔루션으로 해결하곤 합니다. 그러나, 그런 솔루션들은 오래 지속하기가 어렵고 유지하기도 어렵습니다. Concurrent 모드를 통한 목적은 UI 조사 결과를 추상화시키고 그것을 사용할 관용적인 방법을 제공하는 것입니다. UI 라이브러리로서, React는 이러한 일을 할 수 있습니다. - -## 다음 단계 {#next-steps} - -이제 Concurrent 모드에 대해 모두 알게 되었습니다! - -다음 페이지에서는 특정 주제에 대한 자세한 내용을 배웁니다. - -* [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. -* [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 Suspense로 만들어진 UI 패턴들을 설명합니다. -* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드 사용방법을 설명합니다. -* [Concurrent 모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새로운 API 문서입니다. From aeee303b2caac8cc347b449ef7b292a1553c6a08 Mon Sep 17 00:00:00 2001 From: Yohan-Kim2 Date: Sun, 24 Nov 2019 21:10:02 +0900 Subject: [PATCH 14/14] Resolving --- content/docs/concurrent-mode-intro.md | 100 ++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 content/docs/concurrent-mode-intro.md diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md new file mode 100644 index 000000000..6a2a477ce --- /dev/null +++ b/content/docs/concurrent-mode-intro.md @@ -0,0 +1,100 @@ +--- +id: concurrent-mode-intro +title: Concurrent모드 소개 (실험 단계) +permalink: docs/concurrent-mode-intro.html +next: concurrent-mode-suspense.html +--- + + + +
+ +>주의사항 +> +>이 페이지는 **안정된 배포판에서는 [아직 사용할 수 없는](/docs/concurrent-mode-adoption.html) 실험적인 기능들**에 관해 설명합니다. 프로덕션용 앱에선 리액트의 실험 배포판을 사용하지 마세요. 이 기능들은 React에 포함되기 전에 경고 없이 크게 변경될 수 있습니다. +> +>이 문서는 얼리어답터들과 새로운 기능을 궁금해하시는 분들을 위해 작성된 문서입니다. **React에 처음 접해본다면 이러한 기능들을 걱정하지 않아도 됩니다**. 그 기능들을 바로 배울 필요는 없습니다. + +
+ +이 페이지는 Concurrent 모드의 이론적인 개요를 설명합니다. **더 실용적인 설명을 위해서는 다음 섹션들을 참고하세요** + +* [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. +* [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 Suspense로 만들어진 UI 패턴들을 설명합니다. +* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드 사용방법을 설명합니다. +* [Concurrent 모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새로운 API 문서입니다. + +## Concurrent 모드란? {#what-is-concurrent-mode} + +Concurrent모드는 React 앱이 빠른 반응속도를 유지하도록 하고 사용자의 장치 기능 및 네트워크 속도에 적절하게 맞추도록 돕는 새로운 기능들의 집합체입니다. + +이 기능들은 여전히 실험적이며 변경될 수 있습니다. 아직 안정된 React 배포판에 포함되지 않았지만, 실험 배포판에서 그 기능들을 시도해볼 수는 있습니다. + +## 차단 vs 인터럽트 렌더링 {#blocking-vs-interruptible-rendering} + +**Concurrent 모드를 설명하기 위해서 버전 관리를 예를 들어 설명할 것입니다** 팀에서 일하고 있다면 Git과 같은 버전 관리 시스템을 사용하며 브랜치로 작업할 것입니다. 브랜치가 준비된다면 다른 사람들이 해당 작업을 가져올 수 있도록 작업을 마스터 브랜치로 병합 할 수 있습니다. + +버전 관리가 있기 전에는, 개발 작업의 흐름이 지금과는 많이 달랐습니다. 브랜치라는 개념이 없어서 몇몇 파일을 수정하려면 그 파일들을 수정 작업을 완료하기 전까지 작업하면 안 된다고 모든 사람에게 말해야 했습니다. 심지어는 다른 사람과 동시에 일을 시작할 수도 없었습니다 즉, 문자그대로 이러한 제한사항들에 의해 *차단*되었습니다. + +이는 React를 포함한 UI 라이브러리들이 어떻게 오늘날 작용하는지를 설명해줍니다. 업데이트 렌더링(새로운 DOM 노드 생성 및 컴포넌트 내에 있는 코드 실행하는 것을 포함해서)을 시작하면 이 일은 방해받지 않습니다. 이러한 접근을 "렌더링 차단"이라고 합니다. + +Concurrent 모드에서는, 렌더링은 차단되지 않으나 인터럽트는 가능합니다. 이는 사용자의 경험을 개선하며 또한 이전에 사용할 수 없었던 기능들을 사용할 수 있도록 만들어줍니다. [다음](https://reactjs.org/docs/concurrent-mode-suspense.html) [챕터](https://reactjs.org/docs/concurrent-mode-patterns.html)에서 구체적인 예시를 살펴보기 전에, 새로운 기능들의 높은 수준의 개요를 해보려고 합니다. + +###인터럽트 가능한 렌더링 {#interruptible-rendering} + +필터링 가능한 제품 목록을 생각해보세요. 목록 필터에 입력하고 모든 키를 누를 때마다 버벅거림을 느낀 적이 있나요? 제품 목록을 업데이트하는 몇몇 작업은 불가피할 수 있습니다. (예를 들어, 새로운 DOM 노드를 만들거나 레이아웃을 수행하는 브라우저를 만드는 작업) 그러면, *언제* *어떻게* 이런 비중 있는 작업을 수행할까요? + +버벅거림을 해결하는 한 가지 방법은 입력을 "디바운싱"해주는 것입니다 디바운싱하면, 사용자가 타이핑을 멈추고 나서만 목록을 업데이트합니다. 하지만, 타이핑하고 있을 때 UI가 업데이트하지 않는 사실이 실망스러울 수 있습니다. 이에 대한 대안으로, 입력을 “스로틀”하고 목록을 특정 최대 빈도수로 업데이트 할 수 있습니다. 그러나 저전력 장치에서는 여전히 버벅거릴 것입니다. 디 바운싱 및 쓰로틀링은 둘 다 최적이 아닌 사용자 환경을 만듭니다. + +버벅거리는 이유는 간단합니다 렌더링이 시작되면 중간에 중단될 수 없기 때문입니다. 그래서 그 브라우저는 텍스트 입력을 키를 누르는 즉시 업데이트할 수 없습니다. 벤치마크에서 UI 라이브러리(예를 들어 React)가 아무리 잘 보일지라도, 차단 렌더링을 사용하고 컴포넌트의 일정량 작업을 하면 항상 버벅거림을 초래할 것입니다. 그리고 종종, 이에 대한 쉬운 해결책을 찾기 어렵습니다. + +**Concurrent 모드는 렌더링을 인터럽트 가능하도록 만듦으로써 근본적인 문제를 수정합니다** 이러한 사실은 사용자가 다른 키를 누를 때, React는 브라우저에 텍스트 입력을 업데이트하는 것을 차단할 필요가 없음을 의미합니다. 대신에, React는 브라우저가 입력에 대한 업데이트를 paint하고 *메모리 내에* 있는 업데이트 목록을 계속 렌더링할 수 있도록 합니다. 렌더링이 끝나면 React는 DOM을 업데이트하고 변경 사항들을 화면에 반영합니다. + +개념상으로, React가 "브랜치에서" 모든 업데이트를 준비하는 것으로 생각할 수 있습니다. 브랜치 내에서 작업을 중지하거나 브랜치 사이에서 전환이 자유로운 것처럼, Concurrent모드 내에 React는 더 중요한 일을 위해 진행 중인 업데이트를 중단할 수 있고 그리고서 이전 작업으로 돌아갈 수도 있습니다. 이 기술은 비디오 게임에서 [이중 버퍼링](https://wiki.osdev.org/Double_Buffering)을 떠오르게끔 할 수도 있습니다. + +Concurrent모드 기술은 UI에서 디바운싱과 스로틀링의 필요성을 줄입니다 렌더링은 중단이 가능하기 때문에 버벅거림을 피하고자 일부러 작업을 지연시킬 필요가 없습니다. React는 렌더링을 즉시 시작할 수 있지만, 앱에 즉각적인 반응성이 요구될 때는 이 작업을 중단할 수도 있습니다. + +### 의도적인 로딩 시퀀스 {#intentional-loading-sequences} + +Concurrent 모드는 "브랜치에서" 하는 React 작업과 같다고 전에 말했습니다. 브랜치는 단기적인 수정을 할 때뿐만 아니라 장기적인 실행 기능에도 유용합니다. 때로는 기능에 대해 작업을 할 수도 있습니다. 하지만 마스터로 병합할 수 있는 "적합한 state"가 되기까지 몇 주가 걸릴 수 있습니다. 버전 관리의 이러한 측면은 렌더링에도 적용됩니다. + +한번 앱에서 두 화면 사이를 탐색한다고 가정해보겠습니다. 경우에 따라서, 새 화면에서 사용자에게 "충분히 좋은" 로딩 state를 보여주기 위해 필요한 코드와 데이터를 불러오지 못 할 수 있습니다. 빈 화면이나 큰 스피너로 전환하는 것은 어려운 일이 될 수 있지만 일반적으로 필요한 코드와 데이터를 가져오는 데에 그렇게 많은 시간이 소요되지않습니다. **React가 기존 화면에서 조금 더 오래 유지할 수 있고 새 화면을 보여주기 전에 "안 좋은" 로딩 state를 "건너뛸 수" 있다면 더 좋지 않을까요?** + +오늘날 이것이 가능하긴 하지만 조정하기는 어려울 수 있습니다. Concurrent 모드에서는 이 기능이 내장되어 있습니다. React는 먼저 메모리, 비유하자면 "다른 브랜치", 에서 새로운 화면을 준비하기 시작합니다. 그래서 React는 더 많은 콘텐츠를 불러올 수 있도록 DOM을 업데이트하기 전에 기다릴 수 있습니다. Concurrent 모드에서는 React가 인라인 표시기로 완벽하게 상호작용하는 이전 화면을 계속 표시하도록 지시할 수 있습니다. + +### 동시성 {#concurrency} + +위의 두 가지 예시를 살펴보고 Concurrent 모드가 어떻게 통합되는지 살펴보겠습니다. **Concurrent 모드에서 React는 여러 작업을 *동시에*, 다른 팀원들이 각자 작업을 할 수 있는 브랜치처럼, 진행할 수 있습니다** + +* CPU 바운드 업데이트(예를 들어 DOM 노드 만들기 및 컴포넌트 코드 실행)의 경우 Concurrency는 더욱 긴급한 업데이트가 이미 시작한 렌더링을 "중단" 할 수 있음을 의미합니다. +* IO 바운드 업데이트(예를 들어 네트워크에서 코드나 데이터를 가져오는 것)의 경우 Concurrency는 모든 데이터가 도달하기 전에 React가 메모리에서 렌더링을 시작할 수 있으며 빈 로딩 state표시를 무시할 수 있음을 의미합니다. + +중요한 것은 React를 사용하는 *방식*이 똑같다는 것입니다. 컴포넌트, props 및 state와 같은 개념은 근본적으로 동일한 방식으로 작동합니다. 화면을 업데이트하려면 state를 설정합니다. + +React는 휴리스틱을 사용하여 업데이트의 "급함" 정도를 결정하고 몇 줄의 코드를 수정해서 사용자가 모든 상호작용에 대해 원하는 사용자의 경험을 얻을 수 있도록 합니다.. + +## 생산에 연구를 투입 {#putting-research-into-production} + +Concurrent 모드 기능에 대한 공통 주제들이 있습니다. **이 주제들의 목표는 사람-컴퓨터 간 상호작용에 대한 연구 결과가 실제 UI와 통합되도록 돕는 것입니다.** + +예를 들어, 조사에 따르면 화면 간 전환에서 중간 로딩 state를 너무 많이 표시하면 전환이 더 *느리게* 느껴진다고 합니다. 이것이 Concurrent 모드에서 고정된 "스케줄"에 새로운 로드 state를 표시하여 부조화가 발생하는 것 또는 불필요하게 많이 업데이트되는 것을 피하고자 하는 이유입니다. + +마찬가지로 조사 결과에 따르면, 호버나 텍스트 입력 같은 상호 작용은 아주 짧은 시간 안에 처리되어야 하지만, 클릭이나 페이지 전환은 조금 더 오래 걸린다고 해도 지루한 느낌을 주지않는다고 합니다. Concurrent 모드 내부적으로 사용하는 다른 "우선순위"는 사람들의 인식에 대한 조사에서의 상호 작용에 대한 부분과 대략적으로 일치합니다. + +UX(사용자 경험)에 중점을 둔 팀은 가끔 이러한 비슷한 문제들을 일회성 솔루션으로 해결하곤 합니다. 그러나, 그런 솔루션들은 오래 지속하기가 어렵고 유지하기도 어렵습니다. Concurrent 모드를 통한 목적은 UI 조사 결과를 추상화시키고 그것을 사용할 관용적인 방법을 제공하는 것입니다. UI 라이브러리로서, React는 이러한 일을 할 수 있습니다. + +## 다음 단계 {#next-steps} + +이제 Concurrent 모드에 대해 모두 알게 되었습니다! + +다음 페이지에서는 특정 주제에 대한 자세한 내용을 배웁니다. + +* [데이터를 가져오기 위한 Suspense](/docs/concurrent-mode-suspense.html) React 컴포넌트에서 데이터를 가져오기에 대한 새로운 메커니즘을 설명합니다. +* [Concurrent UI 패턴](/docs/concurrent-mode-patterns.html) Concurrent 모드와 Suspense로 만들어진 UI 패턴들을 설명합니다. +* [Concurrent 모드 도입하기](/docs/concurrent-mode-adoption.html) 프로젝트에서 Concurrent 모드 사용방법을 설명합니다. +* [Concurrent 모드 API 참고서](/docs/concurrent-mode-reference.html) 실험적 빌드에서 사용 가능한 새로운 API 문서입니다.