一.개요
기능 면에서 보면, React 16 의 계획에는 4 가지 중요한 특성이 있습니다:
-
Concurrent Mode
-
Hooks
-
Suspense
-
for Code Splitting
-
for Data Fetching
-
for SSR
-
-
Modernizing React DOM
그 중에서, Concurrent Mode(이전에는 Async Rendering 라고 불렸습니다) 는 확실히가장 기대되는 것으로, 변혁을 이끌 가능성이 있습니다(협력 스케줄링 메커니즘은 브라우저 기능으로 일반화될 가능성이 있습니다)
형식만으로 보면, Hooks 는 함수형 컴포넌트의 강화로, 클래스 컴포넌트와 대등하게, 더 나아가 (기대적으로는) 대체하는 것을 가능하게 합니다.실질적인 의미는 더욱 많은 함수형 사상을 프런트엔드 영역에 도입하는 것 입니다. 예를 들어 Effect, Monad 등. v = f(d) 라는 UI 층의 함수형 사고를 제안한 후, 이 길에서의 더욱 깊은 탐구라고 할 수 있습니다
Suspense 는 Code Splitting 시나리오에서 이미 모습을 드러냈으며, 주요 공헌은사용자 경험과 개발 경험에 있습니다. Data Fetching 의 시나리오도同様로, 개발 경험 (데이터 리퀘스트 및 캐시 방식의 통일) 을 향상시킴과 동시에, 사용자 경험 (Loading 의 표시) 도 고려합니다. 한편, SSR 시나리오에서의 Suspense 능력은 전 2 つ와는 달라, 페이지 로딩 퍼포먼스와 사용자 경험의 밸런스를 더욱 많이 고려하며, 서버 사이드 렌더링과 클라이언트 사이드 렌더링의 연계 (Hydration) 를 통해, 페이지를 가능한 한 빨리 실제로 사용 가능한 상태로 하는 것을 기대하고 있습니다
Modernizing React DOM 은 React DOM(6 년) 의 기술적 부채에 대한 리팩토링 계획으로, 코드네임은 React Fire 입니다. 구현을 간소화하고, 현대의 브라우저 DOM 메커니즘에 맞추는 것을 목적으로 합니다. 예를 들어, 이벤트 시스템이라는 불필요한 추상화 레이어를 삭제합니다. 현대의 브라우저 환경에서는 이러한 2013 년의 polyfill 은 더 이상 필요하지 않기 때문입니다
二.Concurrent Mode
Concurrent Mode 는논블로킹 렌더링을 의미합니다:
Concurrent Mode lets React apps be more responsive by rendering component trees without blocking the main thread.
P.S.Concurrent Mode 는 이전 async mode 라고 불렸습니다. 이름을 변경한 것은, 다른 비동기 렌더링 기술과의 차이를 부각시키기 위함으로, 우선도 스케줄링의 개념이 있으며, 타임쉐어링 오퍼레이팅 시스템이 복수의 프로그램을 병행 실행하는 능력에 유사 합니다
계산 집약 (CPU-bound) 형 태스크에 있어, Concurrent Mode 가 가져오는 논블로킹 렌더링 능력은, 큰 컴포넌트 트리를 렌더링하는 동시에, 애플리케이션의 인터랙션 응답 능력을 보증합니다 (프리즈되지 않음). 이는React 의 비전에서 매우 큰 부분입니다
구체적으로는, Concurrent Mode 에서는 시간이 걸리는 렌더링 플로우를 중단할 수 있어, 메인 스레드가 더욱 우선도가 높은 처리를行う 기회를 제공합니다:
It is opt-in and allows React to interrupt a long-running render (for example, rendering a new feed story) to handle a high-priority event (for example, text input or hover).
또한, Suspense 와 연계하여 불필요한 Loading 상태를 스킵할 수 있습니다 (네트워크가 충분히 빠른 경우, Loading 을 반짝일 필요가 없어집니다):
Concurrent Mode also improves the user experience of Suspense by skipping unnecessary loading states on fast connections.
게다가, Concurrent Mode 특성이 의존하는 협력 스케줄링 메커니즘 은, 장래 브라우저가 네이티브 구현을 제공할 가능성이 있습니다 (이미 Chrome 팀과 협력 하고 있습니다)
P.S.스케줄러의 더 많은 정보는, cooperative scheduling 참조
릴리스 버전
React & React DOM 16.x(미릴리스)
공식 자료
三.Hooks
Hooks 는 함수형 컴포넌트에도 상태, 라이프사이클 등의 클래스 컴포넌트 특성 (state, lifecycle, context, ref 등) 을 가질 수 있게 합니다:
Hooks let you use features like state and lifecycle from function components.
게다가, 컴포넌트 트리 구조의 네스트 관계에 강하게 결합하지 않고, 컴포넌트 간에 상태 로직을 재이용하는 능력도 제공합니다:
Hooks let you use features like state and lifecycle from function components. They also let you reuse stateful logic between components without introducing extra nesting in your tree.
예를 들어:
function Example() {
// Declare a new state variable, which we'll call "count"
const [count, setCount] = useState(0);
return (
<div>
<p>You clicked {count} times</p>
<button onClick={() => setCount(count + 1)}>
Click me
</button>
</div>
);
}
이것이 함수형 컴포넌트의「상태」이며, context, ref, 컴포넌트 인스턴스 변수 등도 동様の Hook 방식으로 서포트가 제공되고 있으므로, 함수형 컴포넌트는 클래스 컴포넌트와 거의 동등한 표현력을 획득했습니다
게다가, Hooks 는 큰 기대를寄せられており, React 컴포넌트의 기본적인 형식 (클래스 컴포넌트의 대체 옵션) 이 되는 것이 기대 되고 있습니다:
In the longer term, we expect Hooks to be the primary way people write React components. Our goal is for Hooks to cover all use cases for classes as soon as possible.
그러나, 함수형 컴포넌트를 대폭 강화하는 것���, 단순히 또 하나의 옵션을 늘리기 위한 것뿐만 아니라, 주요 작용은 다음과 같습니다:
-
컴포넌트 트리의 네스트 레벨을削减
-
라이프사이클 로직의 재이용 (함수형 컴포넌트 + Hooks 로, 클래스 컴포넌트의 클래스 (컴포넌트) 인스턴스 레벨에서 재이용할 수 없는 부분을 추출)
수익은 2 방면에 나타납니다:
-
개발 경험
-
컴포넌트 네스트의 wrapper hell 문제를 해결 ("wrapper hell" of render props and higher-order components)
-
라이프사이클 중의 중복 로직을 재이용
-
-
기초 건설
- 대규모 최적화의 장벽을 해결 (예를 들어 인라인 컴포넌트의 컴파일의 난제)
P.S.주의, Hooks 의 제안은 Class 를 폐지하기 위한 것이 아닙니다 가, Hooks 가 널리 적용된 후, Class 서포트를 별개의 package 에 분할하여, bundle 体积를削减할 가능성이 있습니다:
Hooks don't deprecate classes. However, if Hooks are successful, it is possible that in a future major release class support might move to a separate package, reducing the default bundle size of React.
릴리스 버전
React & React DOM v16.8.0
공식 자료
-
[motivation](https://medium.com/ @dan_abramov/making-sense-of-react-hooks-fdbde8803889)
四.Suspense
Suspense 는UI 가 다른 것을 기다려 일시 정지하는 것으로, 기본적인 메커니즘은 렌더링을 일시 정지하고, 폴백 효과를 표시하는 것입니다 (suspending rendering and showing a fallback):
Suspense refers to React's new ability to "suspend" rendering while components are waiting for something, and display a loading indicator.
2 개의 목표:
-
Code Splitting, Data Fetching 등의 시나리오에 편리한 프로그래밍 모델을 제공
-
병행 모드에서의 사용자 경험을 촉진
Our longer term vision for Suspense involves letting it handle data fetching too (and integrate with libraries like Apollo). In addition to a convenient programming model, Suspense also provides better user experience in Concurrent Mode.
Suspense for Code Splitting
React.lazy 로 컴포넌트를 지연 로드하여, 이로 인해 컴포넌트 (트리) 입도의 코드 분할을 실현합니다. 예를 들어:
// This component is loaded dynamically
const OtherComponent = React.lazy(() => import('./OtherComponent'));
function MyComponent() {
return (
<React.Suspense fallback={<Spinner />}>
<div>
<OtherComponent />
</div>
</React.Suspense>
);
}
P.S.React 코드 분할의 더 많은 정보는, React Suspense 참조
릴리스 버전
React & React DOM v16.6.0
공식 자료
-
[practical explanation](https://medium.com/ @pomber/lazy-loading-and-preloading-components-in-react-16-6-804de091c82d)
Suspense for Data Fetching
Code Splitting 과 同様로, 데이터 리퀘스트의 시나리오에도 편리한 통용 방안을 제공하는 것을 희망하고 있습니다:
We'd like to provide officially supported ways to use it for data fetching too.
예를 들어 UI 가 데이터가 돌아오는 것을 기다리고, 그 동안 React.Suspense 로 Loading 을 표시:
// React Cache for simple data fetching (not final API)
import {unstable_createResource} from 'react-cache';
// Tell React Cache how to fetch your data
const TodoResource = unstable_createResource(fetchTodo);
function Todo(props) {
// Suspends until the data is in the cache
const todo = TodoResource.read(props.id);
return <li>{todo.title}</li>;
}
function App() {
return (
// Same Suspense component you already use for code splitting
// would be able to handle data fetching too.
<React.Suspense fallback={<Spinner />}>
<ul>
{/* Siblings fetch in parallel */}
<Todo id="1" />
<Todo id="2" />
</ul>
</React.Suspense>
);
}
최종적인 비전은, 네트워크 라이브러리가 상층 캡슐화를 제공하고, 대다수의 데이터 리퀘스트가 Suspense 를 통하도록 하는 것입니다
react-cache
react-cache 는 Suspense for Data Fetching 의 상상에 실험적인 구현을 제공하고 있습니다
현재 매우 불안정한 단계에 있으며 (캐시 기한 등의 기초 특성조차欠缺하고 있습니다), 일시적인 사용은 권장되지 않습니다. 주요 이유는 다음과 같습니다:
-
의존하는 일부底层 API 가 아직 ready 하지 않아 (Context.write 참조), API 를 최종 확정할 수 없음
-
일부 UI 패턴 서포트가 결여 (예를 들어 컴포넌트 트리 계층에 무관한 Loading)
그러나, 최종적으로는한 세트의 규범을 형성하며, 다른 네트워크 라이브러리 (Apollo 등) 는 규범 설명에 따르기만 하면 Suspense 서포트에 접속할 수 있습니다:
We'll provide a reference implementation of a basic "React Cache" that's compatible with Suspense, but you can also write your own. Data fetching libraries like Apollo and Relay will be able to integrate with Suspense by following a simple specification that we'll document.
릴리스 버전
React & React DOM 16.x(미릴리스)
공식 자료
Suspense for Server Rendering
Suspense 도 SSR 과 연계할 수 있어, 전후단 합벽으로 페이지 로딩 경험을 향상 할 수 있습니다
구체적으로는, 점진적으로 로드하고, 페이지 콘텐츠를 블록별로 렌더링하며, 동시에 Suspense 특성과 연계하여 로딩 중의 시각 경험을 향상:
We started designing a new server renderer that supports Suspense (including waiting for asynchronous data on the server without double rendering) and progressively loading and hydrating page content in chunks for best user experience.
P.S.그 중에서 double rendering 은 전후단 렌더링 결과가 일치하지 않는 경우 (예를 들어 프런트엔드 렌더링이 데이터 리퀘스트에 의존), 상태의 일치를 보증하기 위해, 백엔드 렌더링 결과를 폐기하고, 프런트엔드에서 다시 해당 컴포넌트를 렌더링할 필요가 있는 것을 가리킵니다. 상세는 Hydration 참조
현재 관련 메시지는 적지만, SSR 대폭 리팩토링은 2019 년의 중점 목표인 것은 확정되어 있습니다:
The new server renderer is going to be our major focus in 2019, but it's too early to say anything about its release schedule.
릴리스 버전
불확정
공식 자료
五.Modernizing React DOM
React Fire 라고 불리는 계획으로, 구현을 간소화 (Simplifying) 하고, 현대의 브라우저 DOM 에 맞추는 (Modernizing) 것을 희망하고 있습니다
현재 아직 탐색 단계에 있으며, 구체적인 계획 및 진척은 React Fire: Modernizing React DOM 참조
릴리스 버전
불확정
아직 댓글이 없습니다