React: 비동기 서버 렌더링 지원(렌더링 전 데이터 대기)

이것이 이미 존재하지 않는 주된 이유(내 생각에)는 클라이언트 측에서 기본적으로 렌더링을 연기하는 대신 항상 일종의 로드 표시기를 표시하기를 원하기 때문입니다. (그것은 또한 코드를 훨씬 더 복잡하게 만들지만 아마도 우리는 그것을 다룰 수 있을 것입니다.)

그것 없이는 해결하기 어려운 두 가지 경우가 있습니다.

• 서버 측에서 렌더링하기 전에 데이터를 가져오려면 렌더링할 구성 요소에 대한 정보가 없기 때문에 구성 요소에 데이터 검색을 위임할 수 없습니다.
• 클라이언트 측에서 사전 렌더링된 html을 수신한 후 처음으로 애플리케이션을 마운트할 때 서버에서 검색된 데이터에서 일종의 캐시가 있더라도 비동기 메서드를 사용하여 해당 데이터를 검색할 수 있습니다. 그러면 반응이 방지됩니다. html을 재사용하지 않습니다.

react-async 는 파이버 및 캐시 문제를 해결합니다. 그것은 트릭을 수행하지만 내 관점에서 그것들은 핵심에서만 해결할 수 있는 문제를 해결하기 위한 _hackish_ 솔루션입니다.

@fdecampredon 은 이 주제에 대해 알지 componentWillMount 가 비동기식이고 아무 것도 즉시 반환하지 않는다고 말합니다. 아무것도 없을 때까지 React는 무엇을 렌더링해야 합니까? 그렇다면 아직 데이터가 없는 경우 렌더링에서 아무 것도 반환하지 않는 이유는 무엇입니까? (예, 서버 측을 얻습니다) 또한 componentWillMount 가 실행되기 전에 props가 변경되면 어떻게 됩니까?

개인적으로 컴포넌트가 실제로 격리된 블랙박스이고 로딩 표시기를 구현하지 않는 한 componentWillMount 동안 비동기 요청을 발송하는 것은 잘못된 것 같습니다. 내가 이해하는 한 React 구성 요소는 더 일반적인 OOP 인스턴스로 오인되어서는 안됩니다. 가장 좋은 경우 React 구성 요소는 props의 데이터를 시각화하는 도구입니다. 대화형이면 state도 가능합니다. 뷰와 모델이 아니라 뷰입니다.

내 귀에 그것은 문제처럼 들립니다. React 구성 요소는 비동기 요청을 전달하는 구성 요소가 아니어야 합니다. 모든 데이터를 가져오고 해당 데이터가 준비되면 React.renderComponent 호출해야 합니다. 동일한 솔루션 클라이언트 측 및 서버 측. 비동기 요청이 실패할 경우 선택한 결과로 중단할 수도 있습니다.

내가 잘못 이해한 것이 있으면 언제든지 저를 무시해 주세요. 그러나 React 구성 요소를 보기와 모델로 취급하는 것 같습니다.

@fdecampredon 은 componentWillMount가 비동기이고 즉시 아무 것도 반환하지 않는다고 말합니다. 아무것도 없을 때까지 React는 무엇을 렌더링해야 합니까? 그렇다면 아직 데이터가 없는 경우 렌더링에서 아무 것도 반환하지 않는 이유는 무엇입니까? (예, 서버 측을 얻습니다) 또한 componentWillMount가 실행되기 전에 props가 변경되면 어떻게 됩니까?

모든 경우에 대해 생각하지 않았다는 것을 인정해야합니다 ^^.
이 기능은 최상위 구성 요소를 처음 마운트할 때만 유용하며, 그렇지 않으면 대부분의 캐스트에서 로더 표시기를 표시하려는 것이 사실입니다.

개인적으로 컴포넌트가 실제로 격리된 블랙박스이고 로딩 표시기를 구현하지 않는 한 componentWillMount 중에 비동기 요청을 전달하는 것은 잘못된 것 같습니다. 내가 이해하는 한 React 구성 요소는 더 일반적인 OOP 인스턴스로 오인되어서는 안됩니다. 가장 좋은 경우 React 구성 요소는 props의 데이터를 시각화하는 도구입니다. 대화형이면 state도 가능합니다. 뷰와 모델이 아니라 뷰입니다.

어떤 식으로든 Flux 샘플 에서 수행된 것처럼 '최상위' 구성 요소가 데이터를 검색할 수 있기를 원할 것입니다.
이 샘플에서는 할 일 목록을 검색하는 것이 동기식 작업이기 때문에 매우 간단합니다. 그렇지 않은 경우에는 서버에서 사전 렌더링하는 경우 데이터 없이 처음으로 렌더링합니다(그리고 사전 렌더링된 서버에서 마크업).

하나의 뷰 계층 구조에 의해 표시되는 하나의 데이터 세트가 있는 간단한 애플리케이션의 경우 여전히 문제가 많지 않습니다. 데이터를 미리 로드하고 저장소의 동기 속성을 계속 유지할 수 있습니다.
이제 응용 프로그램 전체에서 재사용하는 여러 모듈로 구성된 응용 프로그램의 경우 해당 모듈을 다른 저장소(데이터 가져오기를 담당함)에서 '구독'할 수 있는 별도의 응용 프로그램으로 처리할 수 있기를 바랍니다.

아마도 내가 잘못된 방식으로 일을 이해하지만 웹 주변의 일부 토론/샘플로 인해 어딘가에 누락된 것이 있다고 생각하게 될 것입니다.

• 일부 샘플 에서는 @petehunt 가 비슷한 것을 달성하려고 시도한 것 같습니다.
• react-nested-router 는 willTransitionTo 에서 유사한 메커니즘을 홍보하고 일부 토론 에서는 아무도 적절한 솔루션을 찾지 못했다고 느낍니다.
• RRouter 는 또한 구성 요소가 렌더링/마운트될 때 데이터를 미리 가져
• 그리고 마지막으로 앞서 말했듯이 반응 비동기식 입니다.

@fdecampredon 명확하게, react-nested-router에서 willTransitionTo 의 목적은 데이터를 로드하기 위한 _아닌_입니다. 특히 해당 메서드에서 약속을 반환하면 실제로 원하지 않는 새 UI 렌더링이 차단되기 때문입니다. 꼭 해야 하는 경우가 아니면.

@fdecampredon 모두가 여전히 문제를 파악하려고 노력하고 있으므로 아무도 확실한 답을 가지고 있지 않아도 놀라지 않을 것입니다. 하지만 Facebook의 개발자들은 이 문제를 몇 번 겪었을 것입니다.

이에 대한 업데이트가 있습니까? 나는 막 React를 탐색하기 시작했고 즉시 이것에 부딪쳤습니다. 많은 사람들이 동형 앱을 빌드하기 위한 솔루션으로 React를 추천하지만 이것이 해결되지 않는 한 단순히 작업을 완료할 수 없다고 생각합니다.

내 귀에 그것은 문제처럼 들립니다. React 구성 요소는 비동기 요청을 전달하는 구성 요소가 아니어야 합니다. 모든 데이터를 가져오고 해당 데이터가 준비되면 React.renderComponent를 호출해야 합니다. 동일한 솔루션 클라이언트 측 및 서버 측. 비동기 요청이 실패할 경우 선택한 결과로 중단할 수도 있습니다.

내가 잘못 이해한 것이 있으면 언제든지 저를 무시해 주세요. 그러나 React 구성 요소를 보기와 모델로 취급하는 것 같습니다.

이것이 사실이라면 React는 약간 다른 템플릿 솔루션/뷰 레이어에 불과합니다. 그리고 그러한 가능성이 있기 때문에 부끄러운 일입니다. @fdecampredon 이 여러 모듈로 구성된 복잡한 응용 프로그램을 언급할 때 정말 이해합니다. React는 이것을 위해 완벽할 것입니다.

이 접근 방식이 구성 요소를 보기 및 모델로 취급하는 것을 의미한다고 생각하지 않습니다. Flux 아키텍처를 보면 React 구성 요소를 _controller-views_로 생각합니다. 이 구성 요소는 데이터를 표시할 뿐만 아니라 사용자 상호 작용을 기반으로 작업을 호출하는 _controller-views_입니다. 그런 다음 작업은 상점(= 모델)을 업데이트합니다. 나에게 그것은 명백한 MVC 아키텍처처럼 들립니다.

문제는 상점을 채우는 초기 조치에 있습니다. 클라이언트 측에서는 권장하는 대로 componentDidMount() 메서드에서 작업을 호출할 수 있는 매우 간단합니다. 반면에 서버 측에서는 작업이 완료되고 저장소가 채워질 때까지 렌더링을 지연시키는 특별한 장소와 일종의 메커니즘이 정말로 필요합니다.

현재로서는 React-async/Fibers + Flux가 유일한 방법인 것 같습니다. Flux의 좋은 점은 구성 요소 상태를 서버에서 클라이언트로 전송하기 위해 인공 캐시가 필요하지 않다는 것입니다(원래 react-async 예제에서 수행한 것처럼). 간단히 저장소를 초기화한 다음 저장소로 보낼 수 있습니다. html 마크업이 있는 클라이언트( 이 예제 참조).

그러나 이 솔루션은 실제로 _hackish_입니다.

비동기식인 componentWillMount가 반드시 필요하다고 생각하지는 않습니다. 라이프 사이클 이벤트가 필요한지조차 확실하지 않습니다. 진짜 문제는 서버 측에서 모든 것이 문자열로 렌더링될 때까지 구성 요소 트리를 분석할 방법이 없다는 것입니다.

이 문제를 해결하기 위한 이상적인 솔루션은 구성 요소 트리를 구축하는 "렌더링"을 허용하는 것입니다. 그러면 트리를 탐색하여 추가 데이터가 필요한 구성 요소를 찾고 더 많은 데이터를 비동기적으로 로드하고 "다시 렌더링할 수 있습니다. " 해당 구성 요소 하위 트리를 만들고 마크업을 플러시할 준비가 되면 해당 트리를 문자열로 변환할 수 있습니다.

이것은 우리가 브라우저에서 할 수 있는 일을 복제합니다: 우리가 원하는 대로 다시 렌더링할 수 있는 가상 DOM이 있습니다. 차이점은 브라우저에서 DOM 업데이트가 암시적일 수 있다는 것입니다. 서버에서는 비동기 데이터를 기반으로 가상 DOM에 대한 업데이트를 수행할 수 있도록 문자열로 렌더링하는 시기에 대해 명시적이어야 합니다.

이 문제를 해결하기 위한 이상적인 솔루션은 구성 요소 트리를 구축하는 "렌더링"을 허용하는 것입니다. 그러면 트리를 탐색하여 추가 데이터가 필요한 구성 요소를 찾고 더 많은 데이터를 비동기적으로 로드하고 "다시 렌더링할 수 있습니다. " 해당 구성 요소 하위 트리를 만들고 마크업을 플러시할 준비가 되면 해당 트리를 문자열로 변환할 수 있습니다. — @mridgway

네, 좋습니다. 현재 서버 측에서 구성 요소를 두 번 렌더링하는 것이 해결 방법으로 사용될 수 있습니다.

React 내에서 지원되기를 원하는 것의 예로 react-nexus 를 참조하고 싶습니다. 실제로 DOM에 마운트하거나 문자열을 작성하지 않고 구성 요소 트리를 구축한다는 점을 제외하고는 기본적으로 mountComponent 작동 방식을 다시 작성합니다. 이를 통해 구성 요소 트리를 탐색하고 트리가 구축되는 동안 비동기 메서드를 실행할 수 있습니다. 이 구현의 문제는 첫 번째 트리를 버리고 어쨌든 React.renderToString 를 호출하지만 사전 렌더링 트리를 가져와서 렌더링/마운트하는 것이 좋습니다.

코어 내에서 이 작업을 기꺼이 수행하고 싶지만 몇 가지 지침이 필요합니다. 요구 사항 중 하나는 비동기로 인해 문제가 발생하지 않도록 ReactContext 를 전역적으로 참조하지 않도록 하는 것입니다. 이와 관련하여 문제가 발생할 수 있는 다른 전역이 있습니까?

@mridgway 내가 실수하지 않았다면 글로벌 ReactContext 는 호환되는 것일 수 있으며 0.14에서 사라질 것입니다. 하지만 제가 _아마도_ 틀릴 수도 있습니다.

@gaearon 예, withContext 지원 중단에서 얻은 의미입니다.

:+1: 이 ATM에 react-router 를 사용 중입니다. @mridgway 의 접근 방식은 매우 합리적으로 들립니다.

이 문제에 대한 약간 다른 견해는 번들러(예: webpack)에서 생성된 코드 청크의 비동기식 로드를 처리하는 방법입니다.

이 티켓( https://github.com/rackt/react-router/issues/1402) 에서 논의된 바와 같이 비동기 렌더링 지원의 문제는 관련 청크가 첫 번째에서 아직 로드되지 않았기 때문에 초기 렌더링이 null로 표시된다는 것입니다. 렌더 패스로 인해 DOM 루트에 <noscript> 가 발생하고 체크섬이 실패합니다. 나중에 모든 것이 빠르게 제자리에 놓이지만, 특히 다운로드할 청크가 적절한 크기(예: > 30KB)인 경우 로컬에서 작업할 때 UI에서 깜박임이 발생하고 현장에서 더 나빠집니다.

큰 앱을 여러 청크로 분할하는 기능은 우리에게 중요하며 데이터 가져오기 문제를 해결했습니다(데이터 종속성을 가져오기 위해 서버에서 렌더링하기 전에 통과할 수 있는 반응 라우터 및 중첩 경로를 사용했습니다). 이것이 마지막 조각입니다. 프론트엔드용 React 솔루션으로 완전히 전환하는 것을 방해하는 퍼즐입니다.

@anatomic 그것은 React의 책임이 아닙니다. 적절하게 청크하고 필요한 모든 청크가 로드될 때까지 렌더링을 연기하는 것은 여러분의 일입니다. 달리 말하자면, 컴포넌트 중 하나가 외부 라이브러리에 종속되어 있는 경우 이를 사용하기 전에 만족시키는 것이 분명히 문제입니다. React는 시도하더라도 이를 수행할 수 없으므로 전반적으로 동일하게 적용됩니다.

<WaitFor for={MyAsyncLoadedCompSignal} until={...} then={() => <MyAsyncLoadedComp ... />} /> 와 같이 자신에게 더 적합한 대체 전략을 자유롭게 구현하세요. 그러나 이것들은 본질적으로 독단적이며 React가 제공해야 하거나 제공해야 하는 것이 아니므로 커뮤니티에 맡기는 것이 가장 좋습니다.

React 구성 요소의 범위 밖에 있는 비동기 항목을 유지하는 것이 좋습니다. 예는 다음과 같습니다.

import React from 'react';
import Layout from './components/Layout';
import NotFoundPage from './components/NotFoundPage';
import ErrorPage from './components/ErrorPage';

const routes = {

  '/': () => new Promise(resolve => {
    require(['./components/HomePage'], HomePage => { // Webpack's script loader
      resolve(<Layout><HomePage /></Layout>);
    });
  }),

  '/about': () => new Promise(resolve => {
    require(['./components/AboutPage'], AboutPage => { // Webpack's script loader
      resolve(<Layout><AboutPage /></Layout>);
    });
  })

};

const container = document.getElementById('app');

async function render() {
  try {
    const path = window.location.hash.substr(1) || '/';
    const route = routes[path];
    const component = route ? await route() : <NotFoundPage />;
    React.render(component, container);
  } catch (err) {
    React.render(<ErrorPage error={err} />, container);
  }
}

window.addEventListener('hashchange', () => render());
render();

Webpack Code Splitting , React.js Routing from Scratch 및 react-routing (곧 제공 예정)을 참조하세요.

@syranide 계속 노력하겠지만 위에 말한 것처럼 바이너리라고 생각하지 않습니다. 우리는 react-router를 사용하므로 라우터가 React 환경 외부에 있는 것이 아니라 구성 요소이기 때문에 혼합에 몇 가지 문제가 발생할 수 있습니다.

<WaitFor ... /> 접근 방식을 사용했다면 첫 번째 렌더링에서 여전히 콘텐츠의 깜박임/소실을 유발하는 다른 DOM을 얻을 수 있습니까?

만약 우리가 접근 방식, 확실히 첫 번째 렌더링에서 여전히 콘텐츠의 깜박임/사라짐을 유발하는 다른 DOM을 얻을 수 있습니까?

깜박임을 원하지 않는 경우(일부는 필요) 렌더링 전에 의존하는 모든 청크가 로드되기를 기다리는 문제입니다. webpack은 즉시 require.resolve 합니다.

추신. 네, react-router와 당신이 사용하는 다른 것들은 확실히 솔루션을 복잡하게 만들지만 여전히 React가 해결해야 할 문제는 아닙니다.

깜박임을 원하지 않는 경우(일부는 필요) 렌더링하기 전에 의존하는 모든 청크가 로드되기를 기다리는 문제입니다. webpack은 기본적으로 require.resolve를 제공합니다.

require.resolve 에 대한 나의 이해는 그것이 모듈 ID의 동기 조회이고 서버로의 여행을 포함하지 않는다는 것이었습니다. 청크 로딩을 관리하기 위해 require.ensure 를 사용하고 있습니다.

우리 코드를 다시 보면 반응 라우터가 서버에서 렌더링한다고 생각하게 만든 다음 표준 클라이언트 측 접근 방식을 따르면 문제를 우회할 수 있다고 생각합니다.

const history = new BrowserHistory();

if (typeof history.setup === "function") {
    history.setup();
}

Router.run(routes, history.location, (err, initialState, transition) => {
    React.render(<Provider redux={redux}>{() => <Router key="ta-app" history={history} children={routes} />}</Provider>, document.getElementById('ta-app'));
});

나는 그것을 조사할 것입니다. require.resolve에 대한 나의 이해는 그것이 모듈 ID의 동기 조회이고 서버로의 여행을 포함하지 않는다는 것이었습니다. 우리는 청크 로딩을 관리하기 위해 require.ensure를 사용하고 있습니다.

죄송합니다. 예, require.ensure . 콜백은 모든 종속성이 충족될 때만 실행되므로 그 안에 render/setState를 넣으면 됩니다.

알겠습니다. 그렇게 하고 있었습니다. 답변 주셔서 감사합니다. 이것은 react-router에서 다루어야 할 필요가 있는 것처럼 느껴지므로 거기에서 토론을 계속할 것입니다. 이 대화를 하기에 잘못된 장소였다면 죄송합니다!

require.ensure 가 가야 할 길이라는 것이 맞습니다. 우리의 궁극적인 문제는 현재 방문 중인 경로에 연결되어야 하므로 라우터에 직접 연결되어야 한다는 것입니다. react-router는 렌더 트리에 연결하는 구성 요소 기반입니다. 위의 해킹이 없으면 모든 것이 비동기식으로 로드되기 전에 트리를 보는 방법과 싸우게 됩니다(또는 최상위 수준에서 관련 청크를 로드할 수 있도록 라우팅 논리를 복제).

require.ensure가 가야 할 길이라는 말씀이 맞습니다. 우리의 궁극적인 문제는 현재 방문 중인 경로에 연결되어야 하므로 라우터에 직접 연결되어야 한다는 것입니다. react-router는 렌더 트리에 연결하는 구성 요소 기반입니다. 위의 해킹이 없으면 모든 것이 비동기식으로 로드되기 전에 트리를 보는 방법과 싸우게 됩니다(또는 최상위 수준에서 관련 청크를 로드할 수 있도록 라우팅 논리를 복제).

나는 react-router에 익숙하지 않지만 여전히 단순히 setRoute(...) => require.ensure([], function() { require(...); setRoute(...); }) 라고 생각하는데 실제로는 실용적이지 않으므로 다른 수준의 간접 참조를 소개합니다. 경로 맵과 각각에 대한 비동기 require.ensure 로더. function asyncSetRoute(...) { loadRoute(route, function() { setRoute(...); }} 도우미를 작성하면 이제 대신 asyncSetRoute 를 호출하고 모든 것이 준비될 때까지 라우터 업데이트를 연기합니다.

의사 코드 및 일종의 일반, 그러나 그것은 나에게 전반적인 접근 방식처럼 보입니다. 반응 라우터가 이것을 제공해야 할 수도 있고 그렇지 않을 수도 있습니다. 아마도 외부 도우미로 제공되는 것이 이상적일 것입니다. 잘 모르겠습니다.

그래서 몇 시간 동안 조사한 끝에 위에서 아래로(?) 모든 것을 공급하지 않는 한 서버 측 렌더링이 _ 불가능 _하다는 것을 이제 막 확인했습니다.

가능한 단기 솔루션:
A. 저장소를 미리 채우고 서버 측 로딩을 동기식으로 만듭니다.

B. 하나의 데이터 개체를 비동기적으로 가져온 후 위에서부터 하나의 데이터 입력으로 모든 것을 공급합니다.

재: '아'. 렌더 구조가 어떻게 생겼는지 이미 알고 있지 않으면 작동하지 않습니다. 내 다양한 ​​컬렉션/모델/API 종속성을 알기 위해 렌더링해야 합니다. 또한 두 개의 서로 다른 API 없이 가져오기를 클라이언트에서 비동기적으로 수행하지만 서버에서는 동기화하려면 어떻게 해야 합니까?

재: 'B'. 기본적으로 위와 같은 문제입니다. 사람들은 각각의 경로와 함께 사용하기 위해 약간의 종속성 JSON을 만들어야 합니까?

React 지원 솔루션을 기다리는 동안 다른 단기 솔루션이 있습니까? 사용자 토지 포크 또는 플러그인이 있습니까? https://www.npmjs.com/package/react-async ?

@NickStefan

문제가 이해가 되지 않습니다. :-(

1. 저장소가 싱글톤이 아닌 경우 Flux 또는 Flux와 유사한 컨테이너(Alt, Redux, Flummox 등)를 사용합니다.
2. 약속을 반환하는 경로 처리기에서 fetchData 와 같은 정적 메서드를 정의합니다.
3. 서버에서 구성 요소에 대한 경로를 일치시키고 fetchData 를 가져와 렌더링 전에 완료될 때까지 기다립니다. 이것은 Flux 또는 Redux 스토어 인스턴스를 미리 채울 것입니다. 저장소 인스턴스는 싱글톤이 아닙니다. 특정 요청에 바인딩되므로 요청이 격리된 상태로 유지됩니다.
4. 프라미스가 준비되면 방금 미리 채운 스토어 인스턴스와 동기적으로 렌더링합니다.

다음은 이 접근 방식을 설명하는 Redux에 대한 좋은 자습서입니다. https://medium.com/@bananaoomarang/handcrafting -an-isomorphic-redux-application-with-love-40ada4468af4

@gaearon 혼란을

이것은 좋은 플럭스 관행이지만 잠재적으로 제한적이지 않습니까? 매우 다른 데이터가 필요한 뷰 트리의 맨 아래에 작은 구성 요소를 추가하면 루트에서 데이터 종속성을 편집해야 합니다.

내가 요구하는 것은 깊이 중첩된 구성 요소가 비동기 데이터 요구 사항을 정의하는 방법입니다.

루트 구성 요소에 그들의 요구 사항을 추가해야 하는 경우 루트를 하위 구성 요소가 필요로 하는 하나의 하위 구성 요소에 연결하지 않습니까?

@NickStefan with react-routing , 예를 들어 비동기 데이터 가져오기는 다음과 같습니다.

import Router from 'react-routing/lib/Router';
import http from './core/http';

const router = new Router(on => {
  on('/products', async () => <ProductList />);
  on('/products/:id', async (state) => {
    const data = await http.get(`/api/products/${state.params.id`);
    return data && <Product {...data} />;
  });
});

await router.dispatch('/products/123', component => React.render(component, document.body));

이러한 솔루션은 작동하지만 모든 데이터 프리페치가 라우터에 바인딩되어 있기 때문입니다. 그것은 대부분의 경우 문제가 되지 않지만(URL이 페이지에 있어야 하는 내용과 필요한 데이터를 정의하는 것은 의미가 있음) 일반적으로 제한 사항입니다. 모든 것을 자체적으로 처리하는 독립형 재사용 가능한 구성 요소(예: Twitter 스트림, 댓글, 캘린더)를 생성할 수 없으며 구성 요소 계층에 삽입하기만 하면 됩니다. 이것을 가능하게 하는 유일한 방법은 react-async 이지만 이것은 거의 해킹입니다.

나는 React 컴포넌트가 단순히 이런 식으로 사용되도록 의도된 것이 아니라 _controller_-views보다 더 많은 보기라고 가정합니다. 아마도 React를 기반으로 완전히 새로운 라이브러리가 등장해야 할 것입니다.

제 꿈은 언젠가 Wordpress, Drupal 또는 Modx와 같은 React를 사용하여 완전한 CMS를 작성할 수 있게 되는 것입니다. 그러나 HTML/PHP 스니펫 대신 React 컴포넌트에서 웹사이트를 구성할 것입니다.

@NickStefan

귀하의 목록에서 서버 데이터 종속성에 대한 솔루션이 루트 구성 요소(정적 방법/링크한 기사)에서만 데이터 요구 사항을 정의하는 것이라고 가정하는 것이 맞는 것 같습니다. 데이터 종속성이 루트에 정의되어 있으면 저장소 등을 미리 채우는 것이 훨씬 쉽습니다.

루트 구성 요소에 그들의 요구 사항을 추가해야 하는 경우 루트를 하위 구성 요소가 필요로 하는 하나의 하위 구성 요소에 연결하지 않습니까?

루트 처리기 수준에서 정확히 루트가 아닙니다. 앱에는 많은 경로 처리기가 있을 수 있습니다. 또한 React Router 와 같은 라이브러리는 중첩 경로 처리기를 지원 배열 이 포함되므로 Promise.all 할 수 있습니다. 이게 말이 돼?

"모든 구성 요소가 종속성을 선언할 수 있음"만큼 세분화된 것은 아니지만 대부분의 경우 데이터 가져오기를 경로 처리기(상단 및 중첩 처리기)로 제한하는 것이 제가 원하는 전부라는 것을 알았습니다. 아래에 props 를 통해 데이터를 허용하는 순수한 구성 요소가 있으므로 가져오는 _알지_조차 하지 않습니다. 그들이 그것을 요청할 수 없다는 것은 의미가 있습니다.

"모든 구성 요소는 종속성을 선언할 수 있습니다" 접근 방식은 일종의 요청 일괄 처리 솔루션이 없는 한 실용적이지 않습니다. <User> 가 API 호출이 필요하다고 선언하고 이제 100개의 <User> 목록을 렌더링한다고 상상해 보세요. 100개의 요청을 기다리시겠습니까? 이러한 종류의 데이터 가져오기 요구 사항 세분성은 요청 일괄 처리 솔루션이 있는 경우에만 작동합니다. 그것이 당신에게 적합하다면, Relay 가 바로 그것입니다. 하지만 이를 위해서는 특별한 백엔드가 필요합니다.

@NickStefan 현재 구성 요소별 비동기 가져오기를 지원하지 않습니다. 우리는 그것을 추가하고 싶습니다. 이 문제는 진행 상황을 추적하지만 아무도 이에 대해 적극적으로 작업하지 않으며 대규모 구조 조정이 필요하므로 시간이 걸립니다.

@gaearon

"모든 구성 요소는 종속성을 선언할 수 있습니다" 접근 방식은 일종의 요청 일괄 처리 솔루션이 없는 한 실용적이지 않습니다.

이것에 대해 좀 더 생각한 후에, 나는 당신의 말에 동의합니다. 내가 찾던 것은 실제로 실용적이지 않습니다.

난 원래 너의 100도예를 들어이 팀 훈련에 괜찮을 것 (즉 단지 저지르는 <UsersContainer> 모든 100 일 개 요구를 않습니다). 그러나 단순히 컨벤션을 갖는 것은 "사람들이 확장할 수 있는" 것이 아닙니다. 루트 또는 라우터에 대한 모든 종속성을 적용하는 것이 가장 좋습니다. Relay는 세 가지 다른 컨테이너(RelayContainer, RelayRootContainer, RelayRouter 등)를 사용하여 루트에서 종속성을 선언하도록 강제합니다. 이는 본질적으로 종속성 선언을 트리 위로 "호이스트"하는 것이 유일한 방법이라는 점을 증명합니다.

안녕하세요!
이에 대한 업데이트가 있습니까?

+1

나는 당신이 정말로 이것에 대해 생각한다면, 당신은 이것을 하고 싶지 않다고 주장합니다. 나는 원래 React가 비동기 렌더링을 하기를 원한다고 생각했습니다. 그러나 이 스레드의 다른 사람들은 그렇지 않다고 확신했습니다.

릴레이에서도 기본적으로 루트 컨테이너 선언, 릴레이 컨테이너 등을 사용하여 종속성을 트리 위로 "호이스트"해야 합니다. 동기 렌더링이 올바른 방법입니다.

비동기식 렌더링은 악몽이 될 수 있습니다. 요청 애니메이션 프레임에서 개별 업데이트를 수행하기 위해 해킹된 백본이 있는 회사 코드베이스에서 작업한 경험에서 이야기합니다.

동의. 나는 이것이 필요하다고 생각했지만 실제로는 뷰가 로드할 데이터를 지정하도록 하는 것이 아닙니다. 보기는 그 자체가 요청의 기능(세션이 있는 경우 사용자의 상태)인 애플리케이션 상태의 기능입니다. 이것이 React의 모든 것입니다. 구성 요소가 로드해야 할 데이터를 지정하도록 허용하는 것은 "단방향 데이터 흐름" 아이디어인 IMO에 위배됩니다.

뷰가 로드할 데이터를 지정하도록 하는 것은 실제로는 거꾸로입니다.

이것이 사실인지 완전히 확신할 수 없습니다. 때때로 구성 요소는 로드할 데이터를 아는 유일한 것입니다. 예를 들어 사용자가 방대한 노드 그래프를 탐색할 수 있는 확장 가능한 트리 보기가 있다고 가정합니다. 어떤 데이터를 로드해야 하는지 미리 알 수 없습니다. 컴포넌트만이 그것을 알아낼 수 있습니다.

그럼에도 불구하고 브리지를 통해 통신하기 위해 비동기가 필요한 웹 작업자(#3092) 내에서 React 코드를 실행하는 아이디어를 추구한다면 이 논의가 훨씬 더 관련성이 있을 수 있습니다.

큰 트리 보기의 예에서 서버 측에서 이미 열려 있는 경로를 사용하여 렌더링할 수 있기를 정말로 원한다면 URL 구조에 해당 경로를 추가합니다. 이와 같은 복잡한 구성 요소가 여러 개 있는 경우 GET 매개 변수를 사용하여 해당 상태를 나타냅니다. 이런 식으로 해당 구성 요소는 SSR의 모든 이점을 얻습니다. 크롤링 가능하고 기록을 사용하여 탐색할 수 있으며 사용자는 내부 노드에 대한 링크를 공유할 수 있습니다. 이제 서버에서 필요한 데이터를 결정할 수 있는 방법도 있습니다. 응답을 렌더링하기 위해 가져옵니다.

update 그래프를 나무로 잘못 잘못 알고 있지만 여전히 해당 그래프에 대한 사용자 보기의 상태가 URL 구조로 표시되어야 한다고 생각합니다. 또한 실제로 React에서 작업한다는 것을 깨닫지 못했습니다. 데이터 계층을 뷰와 동형적으로 통합하기 위한 일부 프레임워크에서 작업하는 경우 정말 좋습니다. 그러나 나는 그것이 보기의 영역을 넘어서고 React가 전체 스택 컨트롤러의 역할을 해서는 안 된다는 데 동의할 수 있다고 생각합니다.

전체 스레드를 읽지 않았으므로 이미 논의되었다면 죄송합니다.

정말 도움이 될 한 가지는 구성 요소를 "시작/인스턴스화"하고 수명 주기 메서드를 실행하지만 개발자가 구성 요소를 html 문자열로 렌더링할 준비가 된 시점을 결정하게 하는 react-dom/server 메서드가 있는 경우입니다. . 예를 들어 개발자는 setTimeout 또는 더 안정적인 것을 사용하여 비동기 메서드가 완료될 때까지 기다릴 수 있습니다.

이것은 현재 이것을 달성하기 위해 redux와 함께 사용하고 있는 "해킹"입니다.

  // start/instantiate component
  // fires componentWillMount methods which fetch async data
  ReactDOM.renderToString(rootEle)

  // all my async methods increment a `wait` counter 
  // and decrement it when they resolve
  const unsubscribe = store.subscribe(() => {
    const state = store.getState()
    // as a result, when there are no more pending promises, the wait counter is 0
    if (state.wait === 0) {
      unsubscribe()
      // all the data is now in our redux store
      // so we can render the element synchronously
      const html = ReactDOM.renderToString(rootEle)
      res.send(html)
    }
  })

이 접근 방식의 문제는 두 번째 ReactDOM.renderToString 가 모든 componentWillMount 메서드를 다시 실행하여 불필요한 데이터 가져오기를 발생시킨다는 것입니다.

얘들 아! 이것은 현재 작업 중인 것입니까? 이 문제의 중요성이 커지고 있다고 생각합니다. 최근에 react redux의 connect 를 dataConnect 로 확장하는 라이브러리를 만들었습니다. 여기서 컨테이너 데이터 요구 사항도 지정할 수 있습니다. 이러한 데이터 요구 사항은 런타임에 번들로 제공되고 단일 요청에서 GraphQL로 쿼리됩니다. 이것이 구성 가능성과 격리를 촉진하고 더 성능이 좋은 가져오기를 보장하기 때문에 이것이 데이터 사양의 미래라고 생각합니다. (Relay에서 본 모든 개념)

위의 문제는 서버 측 렌더링입니다. 내가 어떤 데이터 요구 사항으로 끝날 것인지 정적으로 분석할 수 없기 때문에 현재 DB에서 쿼리할 번들을 가져오기 위해 한 번 렌더링해야 하고 redux 저장소를 숨긴 다음 최종 문자열을 얻기 위해 다시 렌더링해야 합니다. . 문제는 @olalonde 의 문제와 유사합니다.

반응 요소 트리에 대한 작업 및 업데이트를 트리거하고 요청 시 DOM 문자열 결과를 얻을 수 있다면 환상적일 것입니다. 내가 그림을 그리는 방법은 다음과 같습니다.

const virtualTree = ReactDOM.renderVirtual(rootEle);

// get the bundled query from redux store for example
const bundle = store.getState().bundle;

// Fetch the data according to the bundle
const data = fetchDataSomehow(bundle);

// hydrate store
store.dispatch({type: 'hydrate', data});
// components that should update should be marked on the virtual tree as 'dirty'

virtualTree.update(); // this would only update the components that needed update

const domString = virtualTree.renderToString(); // final result

다른 옵션은 모든 후크가 존재하고 didMount와 같이 작동하는 클라이언트 측에서와 같이 마음대로 업데이트하도록 하는 것입니다. 그러나 DOM을 변경하는 대신 가상 DOM 표현을 변경하고 요청 시 문자열로도 렌더링합니다.

여러분은 어떻게 생각하세요? 고려해야 할 사항이 있습니까? 아니면 제가 완전히 잘못 보고 있습니까?

안녕 모두. 저는 이 문제를 구독한지 1년 정도 되었습니다. 그 당시에는 구성 요소가 모듈화의 기본 단위였기 때문에 구성 요소 내에서 로드해야 하는 데이터를 지정할 수 있어야 한다고 생각했습니다. 이 문제는 나에게 정말 중요했고, 나는 그것이 React의 다음 버전에서 반드시 해결될 것이라고 생각했습니다.

그 이후로 저는 REST/HATEOS 이면의 이상에 대해 훨씬 더 깊은 존경심을 갖게 되었습니다. 그 지침 원칙이 다음과 같은 경우 애플리케이션 시스템(브라우저, 크롤러, 애플리케이션 서버, 프록시, CDN 등)에서 나타나는 대규모 단순성 때문입니다. 따랐다. 이 문제와 관련하여 _URL은 애플리케이션 상태의 진정한 표현이어야 합니다_. 요청을 처리하는 데 필요한 정보를 결정해야 합니다. 뷰 레이어인 React는 이것을 결정해서는 안 됩니다. 데이터를 기반으로 구축해야 합니다. 보기는 데이터의 기능이고 데이터는 URL의 기능입니다 .

나는 이것이 좋은 아이디어이지만 현실 세계는 이것이 작동하기에는 너무 복잡하다는 말을 계속 들었기 때문에 과거에 이것을 버리는 것을 주저했습니다. 그리고 때때로 나는 한 발 물러서서 내가 너무 현학적이거나 너무 이상주의적이지 않나 하는 생각을 하게 만드는 예를 듣습니다. 그러나 이러한 예를 숙고하면서 불가피하게 URL에서 응용 프로그램 상태를 나타내는 합리적인 방법을 찾습니다.

• 귀하의 주에는 독립적으로 다양한 매개변수가 있습니까? 별도의 쿼리 매개변수로 표시합니다.
• 상태(또는 그 일부)가 너무 커서 URL에 맞지 않습니까? 이름을 지정하고 변경할 수 없는 데이터 저장소에 저장합니다. 이름/아이디로 참고하세요.
• 상태가 너무 빨리 변경되어 영원히 저장할 수 없습니까? 축하합니다. 합법적인 빅 데이터를 보유하고 저장을 위한 스프링을 확보하고 이를 사용할 기발한 방법에 대해 생각하기 시작했습니다. 또는 부끄러워하고 UPDATE 쿼리로 데이터를 변경하고 나중에 모든 것을 영구적으로 캐시할 수 없다는 것을 받아들일 수 있습니다(*).
• 사용자마다 다르지만 동일한 URL(예: 개인화된 홈 페이지)에서 제공되는 보기가 있습니까? 사용자 식별 시 사용자 ID가 포함된 URL로 이동합니다.
• 이전 URL 구조를 깨는 옵션이 없는 이전 애플리케이션 위에 구축하고 있습니까? 고통스럽다, 나는 같은 배에 있다. 이전 URL 구조를 잘 구성된 URL 구조로 리디렉션하여 세션 데이터(또는 무엇이든)를 URL 경로 세그먼트 및 매개변수로 변환합니다.
• 애플리케이션 아키텍처를 거의 또는 전혀 제어할 수 없습니까? 그것은 React가 설계된 경우가 아니며 상호 호환되는 Wordpress / Magnolia / Umbraco 아키텍처와 같은 것에 적합하도록 React가 엉망이 되는 것을 원하지 않습니다.

그렇지 않았다면 가질 수 없었을 그 모든 일에 대해 무엇을 얻습니까?

• 한 사용자가 URL을 공유하여 다른 사용자를 애플리케이션의 동일한 위치로 데려올 수 있는 기능입니다.
• 브라우저가 제공하는 모든 도구를 사용하여 애플리케이션을 탐색하는 기능. 표준 클라이언트는 해당 요소에 있습니다.
• 클라이언트가 따르기 쉬운 방식으로 복잡한 페이지 매김을 제공하는 기능: 응답의 next 링크. FB 그래프 API가 이에 대한 좋은 예입니다.
• Google 애널리틱스의 사용자 워크플로에 대한 자세한 그래프입니다.
• 요청 로그 외에는 아무 것도 없이 해당 그래프를 직접 구성하는 옵션입니다.
• 혼돈의 길에서 탈출: 모든 요청을 app.get("*", theOneTrueClientonaserverEntryPoint) 로 일치시키는 대신 의도한 대로 서버 애플리케이션 프레임워크를 사용하게 됩니다. 200 OK\n\n{status: "error"} 대신 요청에서 올바른 HTTP 상태 코드를 반환할 수 있습니다. 스타 루트는 매력적이지만 광기로 이어집니다.

이제 스타 도구인 React가 작업을 제어하지 않습니다. 어떻게 데이터를 얻을 수 있습니까? 렌더링할 구성 요소를 어떻게 알 수 있습니까?

1. 데이터 액세스 기능으로 라우팅하고 관련 요청 매개변수에 대한 데이터를 가져옵니다. 전체 URL을 구문 분석하고 완전한 컨텍스트 개체를 가질 때까지 반복합니다.
2. API 요청에 응답하는 것처럼 컨텍스트를 가능한 가장 간단한 응답 객체로 변환합니다. API 요청을 제공하고 있습니까? 그런 다음 완료되고 건조됩니다.
3. 최소한으로 복잡하지만 가능한 큰 개체를 최상위 구성 요소에 전달합니다. 여기부터는 React 컴포넌트 구성이 전부입니다.
4. 문자열로 렌더링하고 응답합니다. CDN이 URL로 식별하고 모든 주에 URL이 있기 때문에 CDN이 이것을 영원히 캐시할 수 있음을 알리십시오(* 위의 이 옵션을 희생하지 않는 한). 물론 CDN에는 무한한 저장 공간이 없지만 우선 순위는 있습니다.

여기에서 트롤을 하려는 것은 아니지만 이 문제의 요청의 핵심 주제가 잘못 안내되어 있고 React가 이를 수용하기 위해 어떤 것도 구현해서는 안 된다고 강력하게 생각합니다. 적어도 여기에서 본 이유는 아닙니다. 작년. 좋은 애플리케이션 아키텍처의 일부 측면은 명확하지 않으며 웹은 특히 제대로 하기 어렵습니다. 우리는 편안함을 위해 우아함을 희생하기보다는 인터넷과 웹을 만든 우리 조상들의 지혜를 배우고 존경해야 합니다.

이것이 React를 훌륭하게 만드는 이유입니다. 바로 보기입니다. 최고의 전망. 보기만. λ

@d4goxn에 동의하지 않아야 합니다. 나는 React를 보기 계층 이상으로 만들려고 하지 않으며 라우팅이 중요하지만 모든 데이터 요구 사항을 지정하기에는 확실히 충분하지 않습니다. 구성 요소/컨테이너 수준에서 데이터 요구 사항을 지정하면 React를 보기 계층 이상으로 만들지 않습니다. 이렇게 하면 앱에 대해 훨씬 더 나은 격리 및 워크플로를 제공할 수 있습니다. 단순히 작업을 단순화하는 것이 아니라 큰 응용 프로그램이 필요합니다. 내 앱에 30개의 경로가 있고 각각에 사용자 프로필 구성 요소를 추가하고 싶다고 상상해 보십시오. 모든 데이터 요구 사항이 각각에 대해 지정된 경로 대안에 따라 해당 데이터 종속성을 추가하려면 30개의 경로를 거쳐야 합니다. 해당 구성 요소의 컨테이너에 데이터 요구 사항을 지정하는 경우 원하는 위치에 구성 요소를 추가하기만 하면 됩니다. 플러그 앤 플레이입니다. 뿐만 아니라 모든 구성 요소 데이터 종속성에 대한 쿼리를 최적화할 수 있습니다. Relay가 이에 대한 좋은 예이며 이에 대한 이야기가 나보다 훨씬 더 잘 설명됩니다.

나는 오래된 지혜에 대해 많은 존경심을 가지고 있지만 그것이 진화와 새로운 표준을 만드는 데 한계가되어서는 안됩니다. 적어도 나는 그렇게 봅니다.

내 제안은 기본적으로 React를 변경하지 않는 것이지만 dom/components 트리를 변경하는 '가상 전용' 방법, 기본적으로 서버 측에서 '실행'할 수 있는 React를 사용하는 것입니다. DOM을 변경하기 위해). 여전히 캐싱과 CDN이 있을 수 있습니다. 오늘날 사이트와 응용 프로그램의 역학이 증가함에 따라 정적 캐싱이 감소하는 경향이 있지만 그것은 또 다른 주제입니다 😄

보기가 데이터에 대한 종속성을 지정하는 경우 종속성 그래프를 최적화하고 이를 최소한의 쿼리로 변환하는 방법이 필요합니다. 보기를 구성하기 전에 데이터를 준비할 수는 없지만 두 단계로 나눌 수는 있습니다. 이것이 이 스레드의 계획을 이해하는 것입니다. 예를 들어 각각 고유한 쿼리가 있는 적당히 복잡한 구성 요소 모음을 살펴보겠습니다. 아마도 그것들은 동일한 구성 요소의 모든 인스턴스가 아니며 단일 쿼리로 축소될 수 있는 패턴이 없습니다. 이것이 GraphQL이 해결하고자 하는 문제라고 생각합니다. 각 데이터 저장소에 대해 GQL 서버를 구현하거나 통합해야 합니다. 최적화된 GQL 쿼리의 어떤 부분을 어떤 데이터 저장소로 처리해야 하는지 정렬하는 것은 꽤 복잡하게 들리지만 내 제안에도 그런 복잡성이 있습니다.

모두 동일한 데이터를 필요로 하는 많은 수의 경로가 있는 예에서 실제로 URL에서 해당 데이터 소스에 대한 식별자를 제외하는 이유로 보지 않을 것입니다. 스택의 루트에 상당히 가까운 작은 데이터 가져오기 미들웨어 모듈을 마운트하면 해당 사용자 개체를 컨텍스트에 연결한 다음 컨텍스트를 더 많은 미들웨어와 함께 최종 경로 처리기로 전달합니다. 루트 React 구성 요소는 컨텍스트의 특정 부분에 신경 쓰지 않을 수 있지만 그것에 대해 관심을 가질 수 있는 다음 수준의 자식에게 전달하거나 자신의 후손이 관심을 가질 수 있도록 전달합니다. 이것이 부당하게 복잡하거나 깊은 배선을 도입하면 Flux 저장소와 같은 것이 필요할 수 있지만 그 자체로 큰 주제입니다.

분리와 고립: 그곳에서 당신의 고통을 느낍니다. 내 제안에서 우리는 저장 및 검색에 최적화된 형식에서 추상적인 단순성에 최적화된 형식으로 데이터를 변환하는 두 개의 매우 다른 시스템을 가지고 있습니다. 그런 다음 내 견해는 구성 요소 계층 구조로 전달됨에 따라 그것을 적합한 형식으로 변환하는 것입니다. 두 시스템에 추가해야 하는 기능을 추가하면서 두 시스템을 느슨하게 연결한 상태로 유지하는 것은 제가 어려운 일이 아니지만 저항이 가장 적은 경로도 아닙니다. 데이터 저장소를 위한 프로그래밍과 동적 UI를 위한 프로그래밍 사이의 정신적 전환은 현실입니다. 우리는 별도의 백엔드 및 프론트엔드 개발자를 갖고 있었고 HTTP는 이 두 패러다임 사이의 인터페이스 역할을 했습니다. 이제 나는 그것을 하나의 응용 프로그램으로 내부화하려고 시도하고 있으며 당신은 그것을 위임하려고합니다.

나는 애플리케이션 내에서 증가하는 복잡성과 활동으로 인해 클라이언트 상태가 서버의 훨씬 더 큰 데이터 세트를 참조하는 매우 작은 개체로 표현되는 것을 배제할 수 있다고 확신하지 않습니다. 대규모 멀티플레이어 1인칭 슈팅 게임을 생각해 보십시오. 많은 일이 빠르게 진행되고 있으며 클라이언트에서 게임 호스트/서버로 필요한 최소한의 정보를 전송하려고 합니다. 얼마나 작은 것을 얻을 수 있었습니까? 모든 입력 상태의 맵. 타임스탬프 + 불확실성 범위, 키보드용 ~110비트 필드, 마우스/조이스틱 및 VR 헤드셋 방향용 수십 바이트. 클라이언트는 예측하고, 낙관적으로 렌더링 및 물리적 처리하고, 서버는 클라이언트의 작은 상태 및 상태 기록에서 엄청난 양의 정보를 도출하고 모든 클라이언트를 수정하고 업데이트하기 위해 상당히 많은 양의 데이터를 반환합니다( 모든 주변 에이전트에 대해 동일한 매개변수, 자산 푸시), 그러나 클라이언트 요청 스트림은 여전히 ​​2KB 요청에 적합할 수 있습니다. 그리고 이는 애플리케이션 아키텍처에 도움이 될 수 있습니다.

Relay와 GraphQL에 대한 교육을 요청하지 않습니다. API가 안정적인 버전에 도달하기 전에 피상적으로만 살펴보았을 뿐입니다(지금 잠겨 있습니까?) 구성 요소를 사용하여 데이터 종속성을 지정하고 가져와야 할 실제 데이터를 결정하는 GraphQL 스키마를 선택하는 것이 여전히 확실하다면, 좋은 계획입니다. 그렇다면 다시 한 번 살펴봐야 할 때일 것입니다. 그 아키텍처에 대해 몇 가지 어려운 질문이 있지만 주제에서 벗어나려고 합니다.

:맥주:

추신: HTTP가 MMOFPS를 위한 좋은 통신 프로토콜이 될 것이라고 제안하려는 것은 아닙니다.

@d4goxn 이에 대한 귀하의 망설임과 회의를

나는 이 수준의 추상화가 갈 길이라고 믿습니다. 나는 Relax CMS에서 그것을 사용해 왔으며 워크플로우와 격리는 함께 일할 수 있는 행복입니다. 뿐만 아니라 요청된 데이터는 ui가 필요로 하는 것 이상도 이하도 아니며 각 구성 요소에 필요한 데이터를 수집하고 병합하여 자동으로 만들어집니다. 이것은 확인에 관심이 있는 경우 Relate http://relax.github.io/relate/how-it-works.html 에서 수행합니다. 이를 통해 내 응용 프로그램의 모든 구성 요소를 포함할 수 있으며 내 응용 프로그램의 독립적인 블록으로 작동하는지 확인할 수 있습니다.

아직 파악해야 할 유일한 것은 서버 측 렌더링입니다. 반응의 소스 코드를 살펴본 후 내가 설명한 대로 이미 솔루션이 있을 수 있다고 생각합니다. 그렇지 않은 경우 반응 팀의 누군가가 이에 동의하면 솔루션을 작업할 수 있습니다.

@d4goxn 나도 감히 당신과 논쟁할 것입니다 :) 당신의 원래 게시물에는 보기가 데이터의 함수이고 데이터가 URL의 함수 라는 진술이 포함되어 있습니다. 나는 이것을 정확히 공개라고 부르지 않을 것입니다. 이것은 완전히 임의적이지 않은 모든 웹 사이트 또는 웹 응용 프로그램에 거의 적용됩니다(예를 들어 열린 대화 상자 창의 상태도 URL의 일부여야 하는지 여부에 대한 질문이 있습니다). 우리 모두는 학교에서 수학을 했으므로 함수가 구성될 수 있음을 압니다. 따라서 실제 문장은 화면에 보이는 것이 URL의 함수 라는 것일 수 있습니다. 다시 말하지만, 실제로 밝혀진 것은 없으며, 단지 명백한 것의 형식화일 뿐입니다.

나에게 주요 질문은 그러한 기능을 구성하는 방법 입니다.

당신이 제안한 접근 방식은 좋은 오래된 서버 측 MVC 애플리케이션과 매우 유사합니다(예: Spring MVC가 좋은 예입니다). 현재 URL은 _비즈니스 로직을 수행하는 해당 컨트롤러 메서드를 활성화합니다. 필요한 모든 데이터를 가져와 뷰에 전달합니다. 이에 대한 내 문제는 다음과 같습니다. 생성된 웹 페이지를 보면 일종의 구성 요소 계층 구조입니다(반드시 React 구성 요소는 아님). 당신이 해야 할 일은 URL에서 계층을 생성하거나 생성하는 것입니다. 하지만 두 번 해야 합니다! 첫째, 어떤 데이터를 가져와야 하는지 알기 위해 컨트롤러의 계층 구조를 디코딩해야 하고, 두 번째로 보기의 계층 구조를 디코딩하여... 음... 실제 보기를 렌더링해야 합니다. 나는 그것이 매우 _DRY_ 접근 방식이라고 생각하지 않습니다.

저는 Spring MVC에 익숙하지 않지만 React를 사용하는 방법과 매우 유사한 방식으로 이 문제를 해결하는 또 다른 MVC 프레임워크(Nette라고 하는 PHP 프레임워크)를 자주 사용합니다. 이 프레임워크는 구성 요소도 지원합니다. 아이디어는 각 구성 요소(예: 양식)에 대해 구성 요소를 인스턴스화하고 특히 _필요한 모든 데이터 로드_를 담당하는 팩토리를 코드에 정의한다는 것입니다. 그런 다음 이러한 구성 요소는 보기의 어느 위치에나 포함될 수 있습니다. 따라서 HTML 코드를 작성하고 _view 계층 구조_를 생성할 때 구성 요소를 삽입하기만 하면 기본 팩토리가 필요한 초기화를 처리합니다. 구성 요소는 작은 독립 컨트롤러처럼 작동하고 자체 수명 주기가 있으며 종속성을 처리하고 뷰에서 매개변수화하여 재사용성을 높일 수도 있습니다.

클라이언트 측에서도 React와 함께 이 접근 방식을 사용해 왔으며 매우 실행 가능한 것 같습니다. React 구성 요소는 처음부터 _controller-views_로 표시되어 왔으며 그렇게 사용합니다. 데이터 가져오기를 담당하는 _controller_ 구성 요소가 있고 시각적 개체에만 관심이 있는 _view_ 구성 요소가 있습니다. 전체 페이지는 두 가지 유형의 구성 요소로 구성됩니다. 그들은 멋지게 분리되어 쉽게 재사용할 수 있습니다.

내 응용 프로그램은 필요하지 않았기 때문에 동형(또는 오늘날 그들이 부르는 보편적)이 아니지만 내가 사용하는 스택은 그렇게 할 수 있어야 합니다(아직 실험적인 Relay를 제외하고 이 스택은 이 문제에서 가장 긴 경로). 참고로 다음과 같습니다.

• 핵심 도구는 react-router 입니다. 각 URL에서 비동기 데이터 요청을 후킹할 수 있으며 클라이언트 측과 서버 측 모두에서 작동합니다. 공식적으로 말하면 이 접근 방식은 앞서 언급한 문제를 겪고 있습니다. 이러한 _controller_ 구성 요소는 불가능합니다. 하지만 여기서 중요한 것은 react-router 의 디자인입니다. 동일한 위치에서 _data-hierarchy_ 및 _view/component hierarchy_를 모두 정의할 수 있으며 실제 경로 정의도 계층적입니다. 그것은 매우 _반응하는 것 같은_ 느낌입니다.
• 전체 상태(데이터)는 redux 로 처리됩니다. 다른 모든 장점 외에도 전체 상태를 단일 개체로 유지하므로 서버에서 개체를 생성하고 클라이언트로 보내는 것이 매우 간단하고 자연스럽습니다. 또한 connect() 접근 방식 덕분에 props를 사용하여 최상위 수준에서 모든 데이터를 아래로 전달할 필요가 없습니다.
• 또 다른 퍼즐 조각은 상태를 가능한 한 작게 유지할 수 있는 재선택 입니다. 또한 디커플링 팩터를 크게 증가시킵니다.

아직 완벽하지는 않지만 이 스레드를 처음 접했을 때 사용할 수 있었던 것보다 상당한 진전이 있습니다. 샘플 구현은 여기 에서 찾을 수

나 역시 데이터 가져오기가 구성 요소 수준에 있을 때 서버 측 렌더링을 수행하는 방법이 필요한 것을 제외하고는 거의 모든 동형 작업을 수행합니다. 지금 당장은 철학적 논쟁을 추가하지 않고, 나는 componentDidMount에서 자신의 데이터를 가져오는 구성 요소와 함께 바닐라 반응(또한 자체 개발 라우팅)을 성공적으로 사용해 왔습니다. 내 구성 요소 및 데이터 종속성을 정의하기 위해 중복 구조를 유지하는 아이디어가 정말 싫습니다. 내 구성 요소 트리에 이미 정의되어 있으며 여기에서는 전체 구성 요소가 완료될 때까지 비동기적으로 가져올 때 데이터를 통합하는 여러 렌더 패스가 필요할 수 있습니다. 트리가 해결되었습니다.

바로 지금, 나는 isomophic react, imo에 대한 이것의 중요성이 커지고 있다는 것을 두 번째로 말하고 싶었습니다. 나는 그 동안 해결책을 찾으려고 노력할 것입니다. 감사 해요.

관심이 있는 경우 트래버서를 수행했습니다. -dependencies.js. 이렇게하면 모든 데이터 종속성을 얻을 수 있습니다 -> 데이터 가져 오기 -> 반응 렌더링을 문자열로.

@decodeman , FWIW에서는 대규모 프로덕션 앱에서 이중 렌더 접근 방식(귀하가 언급한 것과 같은)을 성공적으로 사용해 왔습니다. 이 redux-saga 예제 에서 영감을 얻었지만 일반적인 접근 방식은 모든 유형의 비동기 로딩에서 잘 작동해야 합니다. 로드를 componentWillMount 로 이동하기만 하면 됩니다. 관리 용이성을 유지하기 위해 일반적인 로드 시나리오를 처리하는 고차 구성 요소도 있습니다(예: prop x 하고 nil이면 로드합니다.

또한 구성 요소 내에서 데이터를 로드할 수 있고 일종의 지연 렌더링 방법을 갖는 것이 매우 중요하다고 생각합니다. 양쪽 모두를 행복하게 하기 위해 asyncRenderToString이라는 새 메서드를 만들고 asyncOnLoad 또는 이와 유사한 새로운 "lifecycle" 이벤트를 추가합니다. asyncRender 메서드를 호출하는 경우에만 호출됩니다. 서버 측과 클라이언트 측 사이의 코드 중복 측면에서 이것은 개발자가 일반적인 로딩 코드를 별도의 메소드로 옮기고 asyncOnLoad 및 componentMount 에서 해당 메소드를 호출함으로써 수정할 수 있습니다. asyncOnLoad가 완료되었는지 감지하면 반환된 Promise를 사용해야 합니다(undefined가 반환되거나 메서드가 정의되지 않은 경우 해당 수명 주기 이벤트를 직접 호출한 다음 렌더링해야 함). 그렇지 않으면 Promise가 해결될 때까지 기다립니다.

그런 솔루션이 적절한 서버 측 렌더링을 위해 현재 사용해야 하는 모든 해킹 방법을 해결할 것이라고 생각합니다. 예를 들어 반응 라우터 v4를 사용하여 반응 응용 프로그램의 쉬운 서버 측 렌더링 허용(이는 현재 동형 응용 프로그램을 작동시키는 유일한 방법인 중앙 경로 구성을 더 이상 사용하지 않음)

이것은 스트림 체크 아웃 반응 스트림이라고 하는 문제가 해결되었습니다.

2016년 11월 3일 목요일, Florian Krauthan [email protected]
썼다:

내에서 데이터를 로드할 수 있는 것도 매우 중요하다고 생각합니다.
구성 요소와 일종의 지연 렌더링 방법이 있습니다. 아마도 둘 다 만들기 위해
side happy는 asyncRenderToString이라는 새 메서드를 만들고 새 메서드를 추가합니다.
asyncOnLoad 또는 이와 유사한 "lifecycle" 이벤트. 이것은
asyncRender 메서드를 호출하는 경우에만 호출됩니다. 코드 면에서
서버와 클라이언트 측 간의 중복은 개발자가 수정할 수 있습니다.
일반적인 로딩 코드를 별도의 메소드로 옮기고
asyncOnLoad 및 componentMount의 메서드입니다. asyncOnLoad인지 감지
done은 반환된 Promise를 사용해야 합니다(undefined가
반환된/정의되지 않은 메서드는 해당 항목을 직접 호출해야 합니다.
수명 주기 이벤트 및 렌더링) 그렇지 않으면 약속 때까지 기다립니다.
해결합니다.

그런 솔루션이 우리가 사용해야 하는 모든 해킹 방법을 해결할 것이라고 생각합니다.
현재 적절한 서버 측 렌더링을 위해. 예를 들어 허용
반응 라우터 v4로 반응 응용 프로그램의 쉬운 서버 측 렌더링
(지금은 중앙 집중식 경로 구성을 더 이상 사용하지 않습니다.
동형 애플리케이션을 작동시키는 유일한 방법)

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/facebook/react/issues/1739#issuecomment -258198533,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ATnWLUIEJw4m1Y3A4oGDOBzP6_ajDcqIks5q6g4_gaJpZM4CHAWq
.

@yamat124 반응 스트림을 검색하면 이 프로젝트만 찾습니다: https://github.com/aickin/react-dom-stream

적어도 문서에 따르면 Promise가 해결될 때까지 하위 자식에 대한 다음 렌더링 호출을 지연시키는 데이터를 미리 로드하기 위한 수명 주기 이벤트를 가질 수 있는 방법은 없습니다. 아니면 다른 것을 말씀하시는 건가요?

https://github.com/makeomatic/redux-connect는 어떻습니까?

다시 말하지만 그것은 모두 매우 해킹된 방법입니다. 구성 요소 트리와 독립적인 라우팅이 필요합니다. 그리고 경로에 포함된 "메인" 구성 요소는 로드해야 하는 모든 데이터를 알아야 합니다(시간의 99% 작동하지만 항상 그런 것은 아님). 반응에 지연된 구성 요소 렌더링이 있는 경우 둘 다 더 이상 사용되지 않습니다.

동의합니다. 이것은 아마도 지금 반응에 대해 가장 싫어하는 것입니다. 사람들이 수동으로 수행할 수 있으며 소프트웨어 개발과 관련된 모든 것과 마찬가지로 할 수 있다고 말함으로써 이 기능이 없는 프레임워크를 방어하려고 하면 싫어합니다. 하지만 그렇다고 해서 반드시 그래야 하는 것은 아닙니다. 이 정확한 것이 프레임워크 자체 내에서 해결되어야 하는 것 자체를 지적해야 하는 경우 처리하는 수많은 모듈이 있다는 사실입니다.

Next.js 에는 서버 측 렌더링을 수행하기 위한 async getInitialProps 가 있습니다. 불행히도 여전히 부모로부터 루트까지 다시 자식의 getInitialProps 를 호출 해야 합니다. Apollo GraphQL 클라이언트는 또한 모든 트리를 탐색하여 서버 측에서 데이터 요구 사항을 수집한 다음 모든 것을 다시 보낼 수 있습니다. 다음 + Apollo의 예: https://github.com/sedubois/realate.

이러한 것들을 함께 결합하기 위해 비동기 React 구성 요소 수명 주기 메서드가 있으면 좋을 것입니다.

이번 주에 SSR에 대해 배웠습니다. 제가 작성한 내용이 의미가 있기를 바랍니다 😄

/cc @nkzawa @stubailo

BTW componentWill/DidMount 는 이미 비동기식입니다. 도움이 되나요?

https://twitter.com/Vjeux/status/772202716479139840

@sedubois 는 렌더링하기 전에 React가 약속이 해결되기를 기다

@olalonde 그렇게 보입니다 : https://github.com/sedubois/react-async-poc/blob/1d41b6f77e789c4e0e9623ba1c54f5ed8d6b9912/src/App.js

const getMessage = async () => new Promise((resolve) => {
  setTimeout(() => {
    resolve('Got async message!');
  }, 3000);
});
class App extends Component {
  state = {
    message: 'Loading...',
  };
  async componentWillMount() {
    this.setState({ message: await getMessage() });
  }
  render() {
    return (... {this.state.message} ...);
  }
}

@sedubois 귀하의 예에서 componentWillMount

  async componentWillMount() {
    this.setState({ message: await getMessage() });
  }

반환 undefined 와 약속하지만, 스크린 샷는 렌더링하기 때문에, 약속을 위해 (그렇지 않을 수)까지 기다리지 않습니다 반작용 것을 보여 Loading... 텍스트를.

수정: 수정했습니다.

@sedubois @polytypic 또한 Promise가 전혀 처리되지 않기 때문에 함수 내에서 발생한 모든 오류가 조용히 무시됩니다.

@polytypic @dantman "약속이 전혀 처리되지 않음"이 무엇을 의미하는지 잘 모르겠습니다. await 연산자가 기다리고 있습니다. 오류를 잡아야 합니다. 예제를 업데이트 했습니다(Apollo가 수행하는 것과 유사한 로딩/오류 서명 사용).

    try {
      this.setState({ message: await getMessage() });
    } catch(error) {
      this.setState({ error });
    }

그리고 렌더링:

{error ? error : loading ? 'Loading...' : message}

@sedubois async 함수가 암시적으로 약속을 반환할 때 함수의 모든 throw 는 스택을 던지는 대신 암시적으로 해당 약속을 거부하는 것으로 바뀝니다. 이것은 componentWillMount 가 이제 호출자에게 약속을 반환하고 있음을 의미합니다.

React는 반환 값으로 아무 작업도 하지 않으므로 함수는 이제 누군가가 이를 사용하여 무언가를 할 것이라고 기대하는 Promise를 반환하지만 대신 그냥 버려지는 것입니다.

처리되지 않기 때문에 해당 약속의 거부는 React의 어떤 코드에서도 포착되지 않으며 처리되지 않은 오류는 콘솔에 표시되지 않습니다.

그리고 try..catch를 해도 완벽하게 보호되지는 않습니다. setState 에서 catch에서 오류가 발생하거나 catch에서 오타가 발생하면 해당 오류가 자동으로 사라지고 무언가가 깨졌다는 것을 인식하지 못할 것입니다.

@sedubois 사실, 비동기 메서드는 항상 JavaScript(미래의 JavaScript)에서 약속을 반환하는 것 같습니다. C#에서 async-await 문제에 대해 생각하는 것이 혼란스러웠습니다. _소음 죄송합니다!_

그럼에도 불구하고 스크린샷은 React가 약속이 해결되기를 기다리지 않는다는 것을 분명히 보여줍니다. componentWillMount 호출한 직후 render 를 호출하고 Loading... 텍스트를 렌더링합니다. 그런 다음 setState 호출 후 render 다시 호출합니다. React가 약속이 해결될 때까지 기다렸다면 Loading... 텍스트를 전혀 렌더링하지 않을 것입니다. 대신, 약속이 해결될 때까지 기다렸다가 render 만 호출합니다. 이는 서버 측 렌더링 중에 비동기 IO를 수행할 수 있는 이 문제의 모든 종류의 동작입니다.

@dantman @polytypic 감사합니다 👍 예, 응답을 기다리고 오류를 올바르게 처리하려면 React 내부에서 변경이 필요합니다. 코드에 여기 저기에 await 추가하면 됩니다. 😄

개인적으로 저는 웹 작업자를 사용하여 애플리케이션 상태를 저장하고 변경 시 소품을 내보내고 있습니다(데이터 저장소를 완전히 분리하고 React 구성 요소에서 가져오고 React를 렌더러처럼 취급하여 단방향 흐름 원칙을 유지함). 렌더링할 예상 요구 사항(예: 특정 속성이 true인 경우)이 포함된 메시지입니다.

이렇게 하면 첫 번째 메시지가 중간 "로드 중" 상태인 경우에도 비동기 구성 요소 메서드가 필요 없이 정적 서버 측 렌더링에 사용되지 않습니다.

@sedubois 다른 메서드 스택이 있어야 합니다. 또는 주요 변경 사항. React의 현재 렌더링 방법은 동기화이므로 약속을 반환하는 다른 서버 렌더링 방법이 필요합니다.

@dantman 나는 이 물이 나에게 너무 깊기 때문에 여기에 어떤 의견도 제시하고 싶지 않습니다(내 초기 목표는 Vjeux의 async componentWillMount 해킹을 지적하는 것뿐이었습니다...), 하지만 흠, React는 다음 유형을 볼 수 없습니다. 수명 주기 메서드에 의해 반환된 객체이고 약속인 경우 비동기 처리하고 그렇지 않으면 동기화 처리(현재, 즉 이전 버전과 호환되는 방식으로)?

@fkrauthan이 제안한 것을 좋아합니다. 프라미스 또는 undefined 및 추가 비동기 renderToStringAsync 함수를 반환할 수 있는 수명 주기 메서드 load . 그러나 load 는 항상 클라이언트와 서버에서 호출되어야 합니다. render 또는 renderToString 하는 경우 반환된 약속은 오늘날의 동작과 일치하도록 무시됩니다. renderToStringAsync 하고 load 가 약속을 반환하면 렌더링 전에 약속을 해결해야 합니다.

Next.js 처럼 생성자보다 먼저 호출되는 React async getInitialProps 수명 주기 함수를 추가하지 않으 시겠습니까? 이러한 메서드가 없으면 생성자를 직접 호출합니다.

const props = await (Component.getInitialProps ? Component.getInitialProps(ctx) : {});
...
const app = createElement(App, {
  Component,
  props,
  ...
});

Next.js의 getInitialProps 가 React 구성 요소 수명 주기에 연결되지 않아 최상위 구성 요소에서만 호출할 수 있다는 점을 제외하면 Next.js가 작업을 수행하는 것처럼 보입니다. 그래서 아이디어가 있고 그냥 함께 결합할 수 있습니까?

@sedubois getInitialProps가 올바른 장소가 아니라고 생각합니다. 우선 ES6을 사용하는 사람들은 그 방법이 없거나 사용하지 않습니다. 두 번째로 initalProps + props에 전달된 initalProps 병합 위에 작업하려는 initalProps(기본값일 뿐)에서 작업하고 싶지 않습니다. 따라서 componentWillMount 전에 전달되는 새로운 수명 주기 이벤트를 제안합니다.

@Lenne231 아이디어는 사람들이 이미 해결된 약속에 대한 다른 수명 주기 이벤트를 릴레이할 수 있기 때문에 몇 가지 문제를 일으킬 수 있다고 생각합니다. 이제 동일한 수명 주기 이벤트에 대해 두 가지 다른 동작이 있으므로 약간 까다롭습니다.

따라서 서버와 클라이언트에는 새 수명 주기를 전혀 호출하지 않는 동기화 렌더링 메서드가 하나 있어야 합니다. 그리고 해당 수명 주기를 호출하고 계속 진행하기 전에 약속이 해결될 때까지 항상 기다리는 비동기 버전입니다. 제 생각에는 클라이언트 렌더에도 해당 수명 주기가 필요한지 아니면 서버 렌더에만 필요한지 결정할 수 있으므로 최고의 유연성을 제공할 것입니다.

ES6을 사용하는 사람들은 그 방법이 없거나 사용하지 않습니다.

@fkrauthan 아마도 getInitialState 하시겠습니까? 여기서 저는 새로운 getInitialProps (Next.js에서 사용된 이름)에 대해 이야기하고 있었습니다.

두 번째 요점은 예, constructor 이전보다 componentWillMount 이전에 새 수명 주기 메서드를 사용하는 것이 더 나을 수 있습니다. 이전에 언급한 대로 React 수명 주기를 조정할 수 있는 사치가 없기 때문에 Next에서는 그렇지 않은 것 같습니다. 따라서 React 내에서 이러한 아이디어를 가져오는 것이 좋습니다.

@sedubois 그것도 . 예를 들어 es7 기능을 사용하고 클래스 본문에 static props = {}; 정의합니다. 그렇게 하면 제 생각에는 코드를 더 읽기 쉽게 만들 수 있으며 es7이 공식적으로 출시되자마자 점점 더 많은 사람들이 이 코드로 전환할 것이라고 확신합니다.

참고: 클래스 속성은 "ES7" 기능이 아닙니다. ES7이 이미 완성되었으며 지수 연산자만 새로 추가된 언어 기능이기 때문입니다. 당신이 말하는 것은 2단계 클래스 속성 제안 입니다. 아직 언어의 일부가 아니며 변경되거나 삭제될 수 있습니다.

데이터를 가져오기 위한 반응에서 비동기 함수가 필요하지 않다고 생각합니다. 대신 요청 시 renderToString을 사용하는 가상 렌더러가 있으면 좋겠습니다. 따라서 작업을 설정할 수 있으며 가상 트리는 문자열로 렌더링하기 전에 그에 따라 업데이트됩니다. 이것은 반응에서 좋은 SSR을 달성하는 데 이상적이라고 생각합니다. 데이터를 가져오는 방법과 위치는 개발자에게 맡깁니다.

이전에 언급했지만 좋은 API는 다음과 같습니다(이전에 제안한 내용을 약간 업데이트함).

const virtualTree = ReactDOM.renderVirtual(rootEle);

// get the bundled query from redux store for example
const bundle = store.getState().bundle;

// Fetch the data according to the bundle
const data = await fetchDataSomehow(bundle);

// hydrate store (this will set updates on the virtual tree)
store.dispatch({type: 'hydrate', data});

// final result
const domString = virtualTree.renderToString();

이렇게 하면 Apollo와 같은 일부 GraphQL 클라이언트가 이중 renderToString을 만들도록 강제하는 문제를 피할 수 있습니다. 데이터 종속성을 가장 먼저 가져오고 두 번째는 데이터가 채워진 상태로 렌더링합니다. renderToString이 상당히 비싸기 때문에 이것이 처리 낭비라고 생각합니다.

@bruno12mota 나는 당신의 요점을 알지만 다시 그것을 시뮬레이션하려고 시도하는 라이브러리의 양(당신의 솔루션에는 여전히 수천 개의 라이브러리가 있을 것입니다)은 나에게 그것이 아마도 당신이 해야 하는 것이 아니라 핵심 기능이 되어야 한다는 신호입니다. 위에 빌드합니다. 솔루션은 출력을 얻기 위해 여전히 더 많은 렌더링 호출(가상이지만 여전히 렌더링 호출)이 필요합니다.

@fkrauthan 네, 하지만 가상 렌더는 문자열에 2개의 렌더를 만드는 것보다 훨씬 더 성능이 좋습니다. 제 생각에는 여기에서 주요 문제입니다(SSR의 성능). React의 약한 부분입니다. 반응의 renderToString 를 개선하기 위한 몇 가지 실험이 있었지만 반응 팀에서 이 문제에 대해 실질적인 진전이 없었습니다(여기서 비판하지 않고 놀라운 일을 하고 있습니다).

나는 @bruno12mota 에 동의합니다. 이 문제에 대해서도 잠시 동안 숙고한 적이 있습니다. 이것이 가장 간단한 접근 방식입니다. 렌더링이 "플러시"되어야 하는 시기를 결정할 수 있는 자유는 개발자에게 있습니다.

그것은 모든 것을 훨씬 더 복잡하게 만듭니다.

1.) 코드 관점에서 (코드를 살펴보고 렌더링 비동기를 만드는 것이 VDom을 사용하는 렌더러를 만든 다음 한 지점에서 덤프할 수 있는 렌더러를 만드는 것보다 훨씬 쉬워야 함)
2.) 이제 마운트 해제 이벤트도 다시 고려해야 합니다. 그리고 그것은 사용자 정의 코드를 필요 이상으로 복잡하게 만듭니다. 예를 들어 데이터를 로드하면 데이터를 로드해야 하는 새 구성 요소가 렌더링될 수 있습니다. 이제 갑자기 lib는 어느 위치에서 이미 데이터를 로드한 구성 요소와 어떤 구성 요소에 새 데이터 로드 및 항목이 포함되어 있는지 파악해야 합니다.

@bruno12mota 와 함께 합니다. VDom은 틀림없이 더 "저수준" 솔루션이지만 React 개발자가 구현하기가 더 쉬우며 이전 버전과의 호환성 문제가 없으며 커뮤니티에서 다른 더 높은 수준의 솔루션을 실험할 수 있습니다.

예를 들어, 하나의 상위 수준 솔루션은 비동기 componentWillMount 메서드를 래핑하고 보류 중인 모든 약속을 기다리고 모든 것이 해결되면 VDom.renderToString() 하는 "상위 수준 구성 요소"가 될 수 있습니다. 불행히도 VDom이 없기 때문에 지금 당장은 많이 가져오기는 하지만 내 앱에서 이러한 종류의 SSR 전략을 사용하고 있습니다.

현재 가지고 있는 기능을 변경하지 않는 것이 가장 좋은 방법이라고 생각합니다. 즉, getInitialState, componentWillMount 또는 renderToString이 다르게 작동하지 않도록 합니다.

대신 여기서 논의된 문제를 해결하기 위해 새로운 기능을 추가해야 합니다. 클라이언트에서만 호출되는 함수가 있는 것처럼 서버에서만 호출되는 함수가 있을 수 있습니다.

react-dom/server에 "renderToStringAsync" 기능을 추가할 수 있다고 생각합니다. 일반 renderToString과의 차이점은 Promise를 반환한다는 것입니다.

구현 측면에서 유일한 차이점은 비동기 버전이 Component 인스턴스를 생성할 때마다 render()를 호출하기 전에 먼저 "initialize()"를 호출하고 대기한다는 것입니다. 구성 요소에 "초기화" 메서드가 없으면 즉시 render()를 호출할 수 있습니다.

따라서 다음 예제 앱 구조가 있는 경우:

    ComponentB
    ComponentC
        ComponentD
        ComponentE

프로세스는 다음과 같습니다.

1) instanciate componentA
2) await componentA.initialize();
3) componentA.render()
4) do in parallel(
    instanciate componentB, await componentB.initialize(), componentB.render()
    instanciate componentC, await componentC.initialize(), componentC.render(), do in parallel(
        instanciate componentD, await componentD.initialize(), componentD.render()
        instanciate componentE, await componentE.initialize(), componentE.render()
    )
)
5) render to string

따라서 기본적으로 새로운 선택적 기능인 "initialize"를 사용하는 "renderToStringAsync"라는 새 기능만 있으면 됩니다. 그렇게 어렵지 않을 것입니다.

@VanCoding 은 내가 잠시 동안 생각했던 것과 같은 아이디어를 가지고 있습니다. 클라이언트의 componentDidMount에서 initialize가 자동으로 호출될 수도 있는지 궁금합니다.

따라서 서버에서는 다음과 같습니다.

initialize()
render()

클라이언트에서는 다음과 같습니다.

render() // without data (unless available synchronously)
componentDidMount()
initialize()
render() // with data

react-router v4를 사용하여 반응 서버 렌더링을 구현하고 GraphQL을 사용하여 react-apollo를 구현했습니다.

그것은 server-side-rendering-code-splitting-and-hot-reloading-with-react-router 에서 영감을 받았습니다.

기본적으로 서버 렌더링은 동기화된 구성 요소를 사용하고 클라이언트 렌더링은 비동기화된 구성 요소를 사용하므로 웹팩 비동기 로딩 및 실행 모듈 자바 스크립트.

그건 그렇고 서버 렌더링은 Nashorn 스크립트 엔진(JVM)으로 구현됩니다.

• https://github.com/shendepu/moqui-react-ssr
• https://github.com/shendepu/moqui-react-ssr-demo
• https://github.com/shendepu/react-ssr-starter-kit (아폴로 지점)

클라이언트 렌더링 코드
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/main.js#L63 -L82

서버 렌더링 코드
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/main.js#L128 -L155

경로에서 동기화된 구성 요소와 비동기화된 구성 요소를 구별하는 중요한 위치가 하나 있습니다.
Route의 동기화된 구성 요소
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/routes/Counter/Route.js#L10

RouteAsync의 동기화된 구성 요소
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/routes/Counter/RouteAsync.js#L7 -L23

참고: 파일 이름은 Route.js 또는 RouteAsync.js여야 합니다. 코드는 항상 RouteAsync.js를 가져와야 합니다. Webpack은 서버 렌더링용으로 빌드된 경우 이를 Route.js로 대체합니다.
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/build/webpack.config.js#L72 -L80

따라서 dist 및 dist_ssr 빌드의 두 가지 버전이 있습니다. dist 는 클라이언트용이고 dist_ssr 는 공급업체와 앱의 두 청크만 있는 서버용입니다. . 상점 상태는 index.html의 <script> 에 __INITIAL_STATE__ 로 내보내지고 포함됩니다. 두 가지 버전의 빌드가 있는 이유는 ReactDomServer.renderToString() 가 아직 비동기 구성 요소를 지원하지 않기 때문입니다.

두 가지 버전 빌드 접근 방식의 유일한 문제는 개발 모드에 경고가 있다는 것입니다.
React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:

그러나 클라이언트 버전과 서버 버전의 차이점은 Route.js와 RouteAsync.js뿐이므로 경고를 무시할 수 있으므로 프로덕션 모드에서는 경고가 표시되지 않습니다.

서버 측에서 구성 요소 렌더링 전에 비동기 데이터 가져오기의 경우:

• Rest API: 컴포넌트 사용에 정적 loadData 추가

const { matchedRoutes, params } = matchRoutesToLocation(rootRoute.routes, 
                                                        location, [], {}, rootRoute.pattern)
matchedRoutes.filter(route => route.component.loadData).map(route =>
              route.component.loadData(store, params))

loadData 를 조사하고 실행합니다. MatchedRoutes는 부모가 0 인덱스에 있는 일치하는 경로의 배열입니다. loadData 는 순차적으로 또는 병렬로 실행할 수 있습니다.

• GraphQL 쿼리: getDataFromTree 에서 react-apollo/server 를 사용하여 모든 GraphQL 쿼리를 실행합니다.

BTW: Nashorn Script Engine을 사용하면 한 가지 성능 최적화 기회가 있습니다. 공급업체에는 한 번 실행되고 재사용되는 라이브러리 코드와 폴리필이 포함되어 있으므로 이후 요청에 대해서는 앱 청크만 실행됩니다. 라이브러리가 벤더 청크로 이동되기 때문에 앱은 src에 작은 자바 스크립트 코드만 포함하므로 매번 벤더 청크를 평가하는 것에 비해 성능이 향상됩니다. (모든 자바스크립트는 한 번 컴파일되고 캐시되어 모든 요청에 ​​대해 실행됩니다.)

앱 청크에는 src 코드만 포함되어 있다고 거짓말을 했습니다. 또한 babel-runtime 및 core-js/library 참조하는 복제된 babel-runtime 합니다. babel-runtime 는 index.js 또는 기본 항목이 없으므로 webpack이 모듈로 인식할 수 없기 때문에 공급업체 청크로 이동할 수 없습니다. 그러나 코드 크기는 작습니다.

@VanCoding 의 예를 더 자세히 설명하겠습니다. https://github.com/facebook/react/issues/1739#issuecomment -261577586

initialize는 좋은 이름이 아닐 수 있습니다. 이름은 서버에서만 사용되거나 이 함수가 반환될 때까지 렌더링이 지연되는 환경(일명 클라이언트에서는 사용하지 않음)에서만 사용하도록 의도되었음을 분명히 해야 합니다. 아이디어: getStaticProps , getServerProps , getInitialProps , getAsyncProps ...

또한 이러한 renderToStringAsync 메서드를 개발하는 데 기술적인 또는 다른 장애물이 있는지 여부를 핵심 팀에서 듣는 것이 좋습니다.

@nmaro 글쎄요, 함수는 아무 것도 반환하지 않아야 한다고 생각합니다. 그래서 "get"으로 시작하지 않는 이름을 선호하지만 이것 외에는 여전히 이것이 최선의 방법이라고 생각합니다. 나는 그것이 결국 어떻게 불리는지 상관하지 않습니다.

게다가 약 40줄의 코드로 이에 대한 개념 증명을 수행

따라서 반응 팀이 여전히 이것이 발생하는 것을 원하지 않는다면 타사 라이브러리에서 수행하는 것이 그렇게 어렵지 않을 것입니다.

또는 다음과 같이 renderToString에 옵션을 추가할 수 있습니다.
renderToString(Component, {async: true})

@nmaro 그렇게 하면 제공된 옵션에 따라 함수의 반환 유형이 달라지는데, 이는 좋은 방법이라고 생각하지 않습니다. 함수는 항상 같은 유형의 결과를 반환해야 한다고 생각합니다.

@VanCoding 코드 를 타사 라이브러리로 사용하는 방법에 대한 예가 있습니까?

@VanCoding 멋지다! 하지만 솔직히 반응의 내부 렌더링 알고리즘에 그것을 통합하는 것은 어려울 것이라고 생각합니다. https://github.com/facebook/react/blob/master/src/renderers/dom/stack/server/ReactServerRendering.js를 확인하고 반응의 내부에서 길을 잃습니다... IMO에서 누군가의 의견이 정말 필요합니다. 핵심.

@sedubois 일반 renderToString 함수를 사용하는 것처럼 함수를 사용할 수 있습니다. 그러나 문자열을 직접 반환하는 대신 문자열로 확인되는 Promise를 반환합니다.

따라서 사용하면 다음과 같습니다.

var react = require("react");
var renderAsync = require("react-render-async");
var MyComponent = require("./MyComponent");

renderAsync(react.createElement(MyComponent,{some:"props"}).then(function(html){
    console.log(html);
});

이론적으로 기존의 모든 반응 구성 요소를 일반 renderToString과 동일한 방식으로 렌더링할 수 있어야 합니다. 유일한 차이점은 비동기 구성 요소도 지원된다는 것입니다.

@nmaro 맞습니다. 도움이 될 것입니다.

이에 대한 상태는 무엇입니까?

@firasdib 우리는 여전히 일부 반응 개발자가 의견을 제시하기를 기다리고 있다고 생각합니다.

+1

Google 인덱싱 문제는 SSR을 요구하며 아래에 설명된 모든 짐은 우리가 처리해야 하므로 이 문제는 React가 일반 라이브러리로 성공하기 위해 매우 중요합니다.

JavaScript가 Promise를 기다리는 적절한 방법을 제공했다면 전체 비동기 렌더링이 필요하지 않다고 생각합니다. 그런 다음 날씨를 나타내는 매개변수를 전달할 수 있습니다. 데이터 로드를 동기식(SSR의 경우) 또는 비동기식(실제 웹 브라우저의 경우)으로 지정할 수 있습니다. 데이터 로드 로직은 모든 ​​React 구성 요소의 생성자에서 약속을 시작할 수 있고 componentWillMount에서 대기할 수 있습니다.

그러나 내가 이해하는 바와 같이 React 개발자는 componentWillMount의 유용성에 의심을 표시하고 생성자가 모든 작업을 수행하도록 권장했습니다. 어느 쪽이든 작동합니다.

일부 사람들은 구성 요소를 순수 보기로 만드는 것이 문제를 해결한다고 주장했습니다. 부분적으로 맞습니다. 불행히도 이것은 렌더링 트리가 완료될 때까지 어떤 데이터를 로드할지 모르는 가장 일반적인 경우에는 작동하지 않습니다.

문제의 핵심은 렌더링 기능이 DOMTree에 추가할 구성 요소를 선택하는 논리를 가질 수 있다는 것입니다. 이것이 React가 서버 측 렌더링에 매우 강력하고 적합하지 않은 이유입니다.

IMO의 진정한 솔루션은 모든 발행된 데이터 로딩 약속을 react로 등록할 수 있는 것입니다. 모든 데이터 로드 약속이 완료되면 반응이 렌더링 결과로 우리를 다시 호출합니다. 여기에는 여러 가지 의미가 있습니다.

• DOMtree는 여러 번 렌더링됩니다. 불안정한 데이터 로드 상태에서 안정적인 "로드" 상태로 "안착"하는 라이브 시스템과 같습니다.
• 시스템이 버그가 있는 시스템에서 안정적인 "로드" 상태에 도달하지 못할 위험이 있습니다. 이를 처리하려면 타임아웃을 도입해야 합니다.

그 결과 빠르지 않은 프로세스로 서버 측에서 라이브러리를 훨씬 더 "집중적으로" 사용하게 됩니다.

따라서 나는 여전히 일을 끝내기 위해 일반적인 경우를 손상시킬 해결 방법을 생각하고 있습니다. :)

그 동안 비동기 데이터 로딩 환경에서 SSR을 해결해야 합니다.

1. 데이터 로드 호출은 요청 URL에서 파생되어야 합니다(예: react-router). 모든 데이터 로딩 약속을 단일 약속 목록으로 수집합니다.
2. 그 자체가 약속인 Promise.all()을 사용하십시오. 이 약속이 완료되면 로드된 데이터를 서버 렌더링 기능에 전달합니다.

이 모델은 특정 디자인 아키텍처에 얽매이지 않습니다. 플럭스/리덕스가 약간 도움이 될 것 같지만 내 애플리케이션에서 리덕스 모델을 포기했기 때문에 확실하지 않습니다.

이 모델의 문제는 위의 항목 #1입니다. 간단한 애플리케이션은 모든 데이터 로딩 호출을 알고 있습니다. 독립적인 "모듈"이 있는 복잡한 응용 프로그램에서 이 모델은 원래 React 구성 요소 트리와 렌더링 논리의 일종의 복제가 필요합니다.

render() 함수에 이미 작성된 논리를 반복하지 않고 복잡한 프로젝트에서 SSR이 어떻게 작동하도록 만들 수 있는지 모르겠습니다. Flux가 해결책이 될 수 있지만 경험이 없어서 확신할 수 없습니다.

항목 #1 구현이 모호합니다. react-router 예제에서 우리는 라우터로 해당 경로에 속한 최상위 구성 요소를 반환해야 합니다. 다음 구성 요소를 인스턴스화할 수 있다고 생각합니다.

app.use(function(req, res, next) {
    match({ routes, location: req.url }, (error, redirectLocation, renderProps: any) => {
    if (error) {
        res.status(500).send(error.message)
    } else if (redirectLocation) {
        res.redirect(302, redirectLocation.pathname + redirectLocation.search)
    } else if (renderProps) {
        // You can also check renderProps.components or renderProps.routes for
        // your "not found" component or route respectively, and send a 404 as
        // below, if you're using a catch-all route.
        console.log("renderProps", renderProps)
        for (let eachComp of renderProps.components) {
            // create an instance of component
            // ask component to load its data
            // store data loading promise in a collection
            console.log("eachComp: ", eachComp)
        }
        res.status(200).send(renderToString(<RouterContext {...renderProps} />))
        } else {
        res.status(404).send('Not found')
        }
    })
});

따라서 최상위 구성 요소는 더 이상 "순수한" 구성 요소가 아닙니다. 이러한 구성 요소는 이제 데이터 로드를 트리거하는 기능으로 인해 최상위 컨트롤러 역할을 합니다. Flux 모델은 더 이상 개선되지 않습니다. 단순히 데이터 로드 기능 연결에 대한 경로를 다른 모듈로 이동합니다.

불행히도, 상위 컨트롤러의 자식에 이 방식으로 데이터를 계속 로드하면 반응 렌더링 목적으로 생성된 객체 그래프가 중복됩니다. 일을 단순하게 유지하려면(가능한 경우) 모든 데이터 로드를 최상위 컨트롤러 수준에 넣어야 합니다.

그것이 내가 보는 것입니다.

이러한 SSR의 의미를 깨달았다면 Google 인덱싱 가능한 애플리케이션에 대한 React의 유용성에 대해 두 번 생각했을 것입니다. 아마도 플럭스가 솔루션일 수 있지만 플럭스는 단순한 React 애플리케이션보다 애플리케이션을 전체 수준으로 더 복잡하게 만듭니다. 난 거기에 가본 적있어. 간단한 데이터 로드 기능 대신 여러 파일에서 내 논리를 추적해야 합니다. 이론적인 수준에서 프로젝트를 실행하기 전까지는 정말 좋아 보였습니다. 새로운 사람들은 시작하는 데 어려움을 겪었습니다. 코드 기반에서 redux를 가져온 후에는 그런 문제가 없습니다. 모든 UI 디자인의 복잡성에 대한 답이라고 생각했습니다 :)

이번 주 React Conf 에서 React Fiber(React 16)가 나온 후 다음 작업을 계획하고 있습니다(React 17로 추정).

비동기 React 수명 주기 메서드가 올 수 있음을 의미합니까?

글쎄, 섬유 재료는 대부분 더 빠르고 부드러운 재 렌더링에 관한 것이 아닙니까? 서버에서는 한 번만 렌더링하므로 이러한 변경 사항이 서버 측 렌더링에 영향을 미칠지 확실하지 않습니다.

@VanCoding 은 약간 불분명한 위의 메시지를 업데이트했습니다. 나는 섬유가 끊긴 이후에 대한 그들의 계획을 의미했습니다.

나처럼 여기에 도착한 사람들을 위해 도움이 될 수 있는 반응을 사용하여 사용자 정의 구현을 만들었습니다.

https://github.com/siddharthkp/reaqt

키는 서버에서만 실행되는 asyncComponentWillMount입니다. 여기에 언급된 문제를 피하기 위해 모든 구성 요소가 아니라 진입점 구성 요소에만 사용할 수 있습니다.

@siddharthkp 귀하의 구성 요소가 해결하려고 하는 것이 무엇인지 정말로 알 수 없습니까? 최상위 애플리케이션 React 구성 요소에 대해 asyncComponentWillMount만 지원한다면 왜 라이브러리를 사용해야 합니까? 외부에서 그 약속을 해결한 다음 render를 호출할 수 있습니까? 아니면 내가 뭔가를 놓쳤나요?

@fkrauthan

외부에서 그 약속을 해결한 다음 render를 호출할 수 있습니까?

당신이 옳습니다. 그것이 정확히 하는 일입니다.

매력은 하나의 명령으로 비동기 ssr(+ 코드 분할 + hmr)을 얻을 수 있다는 것입니다. ssr이 쉽지 않기 때문에 구현하지 않는 사람들을 많이 보았고 그것이 동기였습니다.

최상위 애플리케이션 React 구성 요소에 대해서만 asyncComponentWillMount를 지원합니다.

1. 하나의 응용 프로그램 구성 요소가 필요하지 않습니다. 페이지/화면/진입점별로 데이터를 가져올 수 있습니다. ( 여기서 여러 진입점을 홍보)

2. 패턴은 의도적입니다. 트리의 모든 구성 요소가 자체 데이터를 원하는 경우 성능에 나쁜 패턴을 조장할 수 있습니다. 최상위 구성 요소에서 데이터를 가져와서 props로 자식에게 전달하면 데이터가 계속 확인됩니다.

@siddharthkp 귀하의 repo는 Next.js(React Conf BTW에서도 발표됨)보다 어떻게 향상됩니까?

https://github.com/zeit/next.js

어쨌든 타사 라이브러리에 대한 논의는 IMHO에서 벗어난 주제이며, 우리가 관심을 갖는 것은 React 자체 내에서 지원하는 것입니다.

타사 라이브러리에 대한 논의는 주제에서 벗어난 IMHO입니다. 우리가 관심을 갖는 것은 React 자체 내에서 지원하는 것입니다.

완전히 동의 해. reaqt 문제의 특정 질문에 대해 논의할 수

이에 대한 사용 사례는 react-native 및 react-native-vector-icons를 사용하는 것입니다. 나는 Promise에서 받은 데이터에 의해 컴포넌트의 prop이 결정되기를 원합니다.

const AsyncUser = props => fetchUser()
  .then(data => (
     <User {...data} />
   ))

지원된다면 많은 복잡한 코드를 이해하기 쉽게 만들고 새로운 비동기 패턴을 열 수 있을 것이라고 생각합니다.

우리는 동일한 문제가 있습니다. ssr을 수행하고 싶습니다. 예측 소품을 검색할 뿐만 아니라 componentWillMount에서 작업으로 가져온 콘텐츠도 검색하고 싶습니다. 소품이 준비될 때까지 기다렸다가 소품을 문자열로 렌더링하는 방법은 무엇입니까?

이 기능이 유용하다고 생각하는 사람이 있으면 구성 요소가 렌더링될 때 서버와 클라이언트가 모두 렌더링될 때 실행되도록 약속 반환 함수를 구성 요소에 바인딩할 수 있는 react-frontload 라는 라이브러리를 작성했습니다.

이 함수는 서버 렌더에서 '동기적으로' 실행되지만(실제로는 그렇지 않음 ;-) 최종 구성 요소 렌더는 해결될 때까지 차단되고 클라이언트 렌더에서는 정상적으로 비동기식으로 실행되며 페이지가 방금 실행된 경우 클라이언트에서 다시 실행되지 않습니다. 서버 렌더링. 또한 구성 요소별로 실행 시점을 보다 세밀하게 제어하기 위해 지정할 수 있는 옵션이 더 있습니다.

데이터 로딩에 정말 유용합니다. 제가 해결하기 위해 작성한 사용 사례와 거의 비슷합니다. 그것을 밖으로 시도! 😄

https://github.com/davnicwil/react-frontload

<AsyncComponent 
  delayRendering={LoadingComponent}
> 
   {/*return a promise that returns a component here*/}
</AsyncComponent>

데이터가 있다는 것을 알고 있기 때문에 위의 접근 방식으로 할 필요가 없는 모든 조건부 렌더링을 생각해 보십시오.

이에 동참합니다. 아직까지는 React에 부족한 필수 기능이라고 생각합니다. 또한 제3자 라이브러리가 이 주제를 다룰 수 있더라도 이는 내부에서 직접 가져와야 한다는 데 동의합니다.

나는 구현을 생각해 냈습니다. https://github.com/timurtu/react-render-async

아주 좋은 비동기 컴포넌트 인터페이스, @timurtu.

...여러분, 이 스레드와 매우 직접적인 관련이 있는 여러 가지 사항이 있으므로 여기에 참여하고 싶었습니다. 저는 오랫동안 이 스레드를 추적해 왔습니다.

• 하나는 SSR을 고려할 때 경로 수준 데이터 가져오기가 가장 합리적이라고 생각합니다. 그 이유는 다음과 같습니다.
  Redux-First Router 데이터 가져오기: 비동기 미들웨어의 80% 사용 사례 해결
• Redux를 사용한 서버 렌더링은 이제 매우 간단합니다. 이전에는 본 적이 없는 것처럼 Redux-First Router 를 사용하여 이를 수행하는 방법에 대한 단계별 가이드가 있습니다. 10단계의 Pro /w Redux-First Router와 같은 서버 렌더링
• 마지막으로 코드 분할을 올바르게 수행하려면 둘 다 수행해야 합니다 (예: SSR + 분할) . 두 가지를 동시에 수행하는 것이 주요 골칫거리 였으며, 소수에 의해 성공적으로 달성되었으며 지금까지 커뮤니티를 돕기 위한 일반 패키지를 갖고 있지 않은 것으로 나타났습니다. React Universal Component + babel-plugin-universal-import + webpack-flush-chunks (및 extract-css-chunks-webpack-plugin )는 이 문제를 실제로 해결하는 패키지 제품군입니다. 그리고 처음으로. 기본적으로 서버에서 구성 요소를 동기식으로 렌더링할 수 있지만 더 중요한 것은 클라이언트에서 초기 동기식 렌더링을 위해 클라이언트로 렌더링된 정확한 청크를 전송하는 것입니다. webpack 플러그인을 통해 CSS 청크 스타일시트를 얻을 수도 있습니다. 이것은 @timurtu가 공유한 것과 main.js 로드, 구문 분석, 평가, 렌더링 및 몇 초 후에 동적 가져오기를 요청해야 하는 많은 구성 요소와 다릅니다. 이들은 스타일이 지정되지 않은 콘텐츠의 플래시(FOUC)를 해결하지만 서버에서 렌더링된 정확한 청크를 페이지에 포함하지 않는 솔루션입니다. Universal( 내 패키지 제품군의 이름)을 사용하면 기존 웹앱처럼 작동하는 동기식 방식으로 TTI(Time to Interactive) 를 훨씬 빠르게 수행할 수 있습니다. React Universal Component 2.0 & babel-plugin-universal-import 에서 이에 대해 자세히 알아볼 수 있습니다.

경로 수준 대 구성 요소 수준 장단점을 다루지 않았다는 것을 알고 있지만 첫 번째 링크는 주로 그것에 중점을 둡니다. 기본적으로 데이터를 (병렬이 아닌) 순서대로 가져와야 하는 중첩 구성 요소가 있는 경우 SSR에 좋지 않은 구성 요소 수준으로 요약됩니다. 경로당 하나의 가져오기만 올바르게 수행할 수 있다면 componentDidMount 에서 수행하는 대신 데이터 종속성을 경로 엔터티에 첨부하여 계약을 공식화하는 것이 좋습니다. 위의 많은 다른 사람들도 이와 같은 결론에 도달했습니다. Redux-First Router 는 Redux를 즐겁게 작업할 수 있도록 하는 일종의 "계약"에 따라 이것을 매우 훌륭하게 공식화합니다.

Redux-First Router 는 많은 기존 패러다임을 다시 새로 만들지만 놀랍게도 Redux 에코시스템에서 누락된 부분으로 딱 맞습니다. Redux의 워크플로에 고유한 라우터를 원했다면 Redux-First Router를 사용해 보십시오. 비교적 새롭고 오픈 소스를 처음 접하는 사람이지만 기본적으로 1년 동안 작업한 작업이며 출시된 지 2개월 만에 많은 관심을 받았습니다. 사람들은 그것을 사랑합니다. 꼭 한번 보시고 결정하시길 바랍니다 :).

다음은 React Router보다 Redux를 위한 훨씬 더 나은 솔루션과 또한 우수한 Redux-Little Router가 불행히도 놓친 방식으로 비전을 올바르게 얻는 방법을 설명하는 출시 기사이기도 합니다.
사전 출시: Redux-First 라우터 — Redux-Little-Router를 넘어선 단계

RLR과 RFR의 주요 차이점은 RFR이 항상 LOCATION_CHANGED 대신에 경로당 다른 작업 유형(예: URL 변경)을 전달한다는 것입니다. 이렇게 하면 다른 작업과 마찬가지로 리듀서에서 URL 변경을 고유한 유형으로 전환할 수 있습니다. 작게 보일 수 있지만 큰 차이를 만듭니다. 그렇기 때문에 Redux 랜드에서는 불필요한 <Route /> 컴포넌트가 필요하지 않습니다. Redux-First Router 가 thunks 경로의 데이터 가져오기에서 React Native, React Navigation, 코드 분할, 프리페칭 등에 이르기까지 지원하는 기능의 방대한 목록도 있습니다.

사람들의 생각을 듣고 싶습니다.

@faceyspacey 감사합니다. 예를 들어 비동기 데이터를 기반으로 props를 설정하려는 경우 react-native-vector-icons 가 아이콘을 약속으로 반환할 수 있는 문제를 해결한 것 같습니다. 확실히 사물을 보는 다른 방법이지만 비동기 구성 요소를 상태에 연결하는 componentWillMount 또는 redux X_GET_START , X_GET_END 및 X_GET_ERROR 작업 상용구를 줄입니다. 구성 요소를 렌더링하기 위해 해당 요청을 한 번만 수행하려는 경우. 데이터 폴링과 같은 작업을 수행하는 경우 상태 저장 및 redux를 사용하는 것이 더 합리적일 수 있습니다.

@faceyspacey 경로 수준에 대해 말씀 알지만 필요한 데이터를 가져오는 데만 의존하고 주변의 다른 모든 것을 동기적으로 렌더링하는 작은 구성 요소를 사용하는 것이 더 좋지 않을까요?

더 나은? 어디에? React Native에서? Facebook과 같은 대규모 조직에서 React Native 앱을 사용하시나요?

아마도 React Native에있을 것입니다. 내가 보기에는 SSR이 있을 때 논쟁이 없습니다. 다시 한 번, 가져오기를 수행할 수 있는 하나의 구성 요소로 제한하지 않는 한 요청당 여러 가져오기 없이 원하는 작업은 불가능합니다. 이 시점에서 경로 엔터티와의 계약을 공식화하는 것이 좋습니다.

React Native와 SPA는 물론입니다. 그러나 내장된 데이터 뎁이 있는 구성 요소를 테스트하는 것은 고통스러운 일입니다. Apollo에는 여기에 몇 가지 항목이 있지만 마지막으로 데이터 쌍 구성 요소 테스트를 정말 올바르게, 즉 매끄럽게 하기 위해 긴 할 일 목록이 있는지 확인했습니다. 설정하고 조롱하기 쉬운 하나의 저장소가 있는 설정을 선호합니다. 모든 테스트에서 그 방법을 재사용할 수 있습니다. 그런 다음 거기에서 구성 요소 테스트는 스냅샷 촬영을 통한 간단한 동기 렌더링입니다. 구성 요소에 데이터 dep를 추가하면 React 테스트가 덜 직관적이 됩니다. 그러나 사람들은 그것을 하고 그것을 자동화합니다. 표준이 적고 이제 사용자 지정 임시 코드에 더 가깝습니다. 채워야 하는 모든 비동기 구성 요소에 대해 잠재적으로 다른 전략을 사용하는 것보다 매우 분명한 방식으로 비동기적으로 채워질 수 있는 저장소를 갖는 것이 더 생산적입니다.

SSR이 없고 테스트 전략이 원활하고 방해가 되지 않는 경우 구성 요소 수준에 반대하지 않습니다. 당신이 거대 기업이라면 모든 개발자가 최상위 경로 레벨을 건드릴 필요가 없고 잠재적으로 다른 개발자를 위해 그것을 깨뜨릴 필요가 없기 때문에 의미가 있습니다. 이것이 FB가 Relay와 GraphQL을 통해 이 경로를 개척한 이유입니다. 문제의 사실은 이 배에 진정으로 세계에서 100개 회사만 있는 것과 같습니다. 그래서 저는 코로케이션을 대부분의 사람/앱/회사에서 현실보다 과장된 것으로 봅니다. 일단 라우트 수준을 이해하고 Redux-First Router 처럼 잘 수행하는 패키지를 갖게 되면 구성원이 라우트 수준을 만질 수 있는 팀을 위한 접근 방식을 개발하기가 훨씬 더 쉬워집니다. 코드샌드박스 홈페이지에서 데모를 확인하세요.

https://www.codesandbox.io

기본적으로 작업이 어떻게 완료되었는지 확인하고 나면 귀하의 의견을 듣고 싶습니다. 이것은 SPA임을 명심하십시오. 따라서 SSR 예제에 대한 데모 리포지토리 또는 상용구 를 검토해야 합니다. 그러나 이것은 좋은 시작입니다.

가장 쉬운 방법은 비동기 렌더 메서드를 지원하는 것이라고 생각합니다(렌더는 약속을 반환합니다). 루트 구성 요소 대기 자식 구성 요소 렌더링을 허용하고 물론 렌더링 결과는 약속이 될 것입니다. 나는 https://github.com/3axap4eHko/preact-async-example 에 preact에서 이와 같은 것을 구현했습니다.

@faceyspacey 위의 자세한 답변에 감사드립니다. 저는 Redux-First Router의 아이디어가 정말 마음에 듭니다. 확실히 제 모든 문제를 해결하고 이전보다 훨씬 더 투명하고 깨끗해졌습니다.

큰 감사를 드린다!

@raRaRa 마음에 경로 수준 데이터 가져오기에 대한 좋은 추상화가 없었다는 것입니다. React React v3에는 콜백이 있었고 v4에는 우수한 패턴(특히 react-router-config 패키지)이 있지만 명확하지 않고 v4에서 일급이 아닙니다. 그것은 나중에 생각입니다. 그러나 더 중요한 것은 Redux에 존재하지 않는다는 것입니다. 따라서 redux 사용자가 완전한 "경로 수준" 추상화를 갖게 된 것은 이제서야 처음입니다.

이제 RFR을 통해 "경로 수준" 대 "구성 요소 수준"의 중요성에 대해 다시 생각하게 될 것입니다. Relay 및 Apollo와 같은 것들은 구성 요소에 대한 데이터 종속성을 페어링하는 것과 관련하여 많은 과대 광고를 만들었습니다. 하지만 이 두 가지를 사용하지 않으면 수명 주기 처리기에서 작업을 수행하여 어느 시점에서 상처의 세계에 빠지게 될 것입니다. .

그것은 결국 RFR이 Apollo와 경로 수준 통합을 갖게 될 것이라고 말했습니다. 앞서 언급한 드문 예외를 제외하고 구성 요소 수준에서 작업을 수행할 때 얻을 수 있는 이점은

React Native + Apollo의 경우 SSR이 없으므로 서버에서 순차적 데이터 가져오기가 발생할 가능성이 있기 때문에 문제가 적습니다. 그러나 화면이 너무 작을 때 구성 요소 수준의 데이터 가져오기가 정말로 필요합니까? 일반적으로 데이터 측면에서 각 "장면"에 필요한 것이 무엇인지 알고 있습니다. 백만 개의 그래프, 여러 테이블 등이 있는 데스크탑 웹 패널 대시보드와 다릅니다. 한 가지 사용 사례는 아마도 구성 요소 수준이 이해되기 시작하는 가장 큰 주요 장소일 것입니다. 그러나 거기에서도 모든 위젯에 대한 모든 요구 사항을 한 곳에서 지정하고 Apollo를 통해 가져올 수 있습니다. 아직 충분히 고려하지 않았지만 기본 아이디어는 GraphQL 데이터 요구 사항을 경로에 첨부한 다음 구성 요소에서 다른 Redux 데이터와 마찬가지로 데이터에 연결하는 것입니다. 보다 구체적으로 말하면 react-redux의 connect 와 Apollo의 동등한 기능을 모두 제거하는 것입니다. 나는 단지 하나를 원하고 우리는 그것이 더 아첨하기를 원합니다. Apollo를 사용하려면 구성 요소에서 진정으로 원하는 것에 액세스하기 위해 더 깊이 중첩된 데이터를 구조화해야 합니다. 비전은 일반 Redux와 경로 수준에서 graphql 사양을 더한 것처럼 보이는 한 가지 방법입니다.

내가 간신히 살펴봤기 때문에 그것에 대해 이야기하기에는 다소 시기상조이지만, 경로 수준이 앱에 대한 올바른 접근 방식이라면 Apollo + GraphQL도 예외는 아니어야 합니다.

마지막으로 모든 데이터 종속성과 비동기 작업이 구성 요소에서 분리되어 있으면 테스트가 훨씬 쉬워집니다. 관심사 분리는 데이터 가져오기에 대해 걱정할 필요 없이 구성 요소를 테스트할 수 있을 때 주요 생산성 향상 효과입니다. 물론 테스트에서 미리 비동기 가져오기를 수행하여 저장소를 채워야 하지만 구성 요소에서 분리하면 모든 테스트에서 사전 작업에 사용하는 일부 setup 도우미 함수에서 이러한 작업을 쉽게 형식화할 수 있습니다. 구성 요소가 렌더링되는 방식을 테스트하기 전에 저장소를 채우세요. :)

@faceyspacey 전적으로 동의합니다. 그러나 Apollo나 GraphQL을 사용해 본 적이 없음을 인정해야 합니다. 확실히 확인하고 사용 사례에 어떻게 맞는지 확인할 것입니다.

저는 기본적으로 컨트롤러에 대한 모든 데이터와 종속성을 가져오는 MVC 패턴을 사용하여 웹 애플리케이션을 작성하는 데 매우 익숙합니다. 그런 다음 뷰 또는 비즈니스 로직에 데이터를 주입합니다. 당신이 말했듯이 보기가 데이터 가져오기와 연결되지 않기 때문에 테스트가 훨씬 쉬워집니다.

View 부분이 데이터를 가져오고 비즈니스 로직을 수행하는 MVC 응용 프로그램을 보았는데 끔찍합니다. 둘 다 일부 보기/구성 요소에 숨겨져 있고 테스트가 더 어려워지거나 불가능해지기 때문에 가져올 데이터가 무엇인지 전혀 모릅니다.

저에게 Redux-First Router는 MVC의 컨트롤러 부분과 매우 흡사합니다. 이것은 매우 의미가 있습니다 :)

감사합니다.

하루가 끝나면 새로운 스택은 다음과 같습니다.

남: 리덕스
V: 반응
C: Redux-First 라우터(곧 "Rudy" 로 이름 변경 예정)

React(특히 Redux)가 나왔을 때 우리 모두는 MVC의 고대 지혜를 버리고 싶어하는 것처럼 보였습니다. 그러나 궁극적으로 단순히 이를 지원하기 위한 도구가 아직 구축되지 않은 것 이상은 아니라고 생각합니다. 결국 우리는 반응적인 클라이언트 우선 애플리케이션에서도 여전히 MVC의 이점을 크게 누리고 있습니다.

새로운 클라이언트 우선 스택과 기존 서버 측 MVC에서 약간 다르게 작동할 수 있지만 기본적으로 동일한 3 분리된 관심사입니다.

3 간의 상호 작용/동작의 차이점이 무엇인지에 관해서는 기본적으로 과거에는 컨트롤러가 초기 단계에서 모델을 얻은 다음 뷰를 렌더링한다는 것입니다. 이제 컨트롤러(RFR)가 뷰를 즉시 렌더링하고("UI 모델", 즉 Redux 상태를 통해 선택됨) 컨트롤러가 도메인 모델 (Redux 상태에도 저장됨)을 찾으면 뷰를 두 번째 로

안녕하세요 여러분, 이 링크를 보십시오. 다음은 데이터 서버 측 렌더링 예입니다. https://github.com/bananaoomarang/isomorphic-redux

@harut55555 idk

변경 사항이 있습니까? 릴리스 16 반응 및 대부분의 솔루션이 작동하지 않음

현재 접근 방식은 redux observable 또는 redux thunk와 같은 도구와 함께 redux를 사용하는 것이라고 생각합니다.

나의 사용 사례

<App>
    <Page>
        <AsyncModule hre="different.com/Button.react.js" /> downloaded from external url on server or client
    </Page>
</App>

문제는 앱을 렌더링하기 전에 내가 가질 구성 요소의 종류를 모른다는 것입니다.

단지 궁금한 구성 요소 대신 데이터/컨텐츠를 다운로드하지 않는 이유는 무엇입니까?

언제? 동적 페이지가 있고 구성 요소가 있을 수도 있고 없을 수도 있습니다.

조건부 렌더링을 원하는 것 같습니다 https://reactjs.org/docs/conditional-rendering.html

라우팅 문제라고 생각합니다. 반응은 렌더링 데이터를 관리하고 요청하지 않고 페이지를 렌더링해야 합니다.

Apollo의 @graphql 를 사용하면 데이터 로드가 매우 간단해지고 React-Router v4 구성 요소 기반 API는 구성 가능한 라우팅을 간단하게 만듭니다. 둘 다 Redux의 애플리케이션 상태와 직교합니다.

데이터 가져오기를 기다리는 단일 패스 스트리밍 렌더링을 수행하려면 render() 가 약속을 반환할 수 있어야 합니다(클라이언트에서는 지금처럼, 서버에서는 약속만 반환).

그러면 @graphql 는 데이터가 로드된 후 render()에 대한 약속을 간단히 반환할 수 있습니다. 나머지는 모두 평범한 React입니다.

몇 달 전 나는 JSConf 아이슬란드에서 React의 다가오는 비동기 렌더링 기능을 설명하는 연설을 했습니다(두 번째 부분 참조): https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react -16.html. 이것은 클라이언트 측 데이터 가져오기에 관한 것입니다.

이제 @acdlite 는 React 구성 요소에서 서버의 데이터를 비동기식으로 대기하고 준비가 되면 마크업을 점진적으로 플러시하는 데 동일한 개념을 적용하는 방법에 대해 설명했습니다. https://www.youtube.com/watch?v= z-6JC0_cOns

이 강연을 즐겁게 시청하시기 바랍니다! 1년 정도 지나면 이 문제를 마무리하고 이에 대한 공식 전략을 세울 수 있을 것입니다.

링이 생각나네요. 우리는 미래를 함께 계획하며 결혼합니다. 이제 그만하고 저를 만나러 오세요. 시간은 항상 사랑

ReactDOMServer.renderToStaticMarkup 를 사용하여 트리를 탐색하고, 비동기 종속성에 도달하는 위치에 책갈피를 배치하고(일반적으로 API에서 데이터 로드), 전체 트리가 해결될 때까지 이러한 종속성이 해결될 때 트리를 계속 탐색할 수 있습니다. 그런 다음 최종 ReactDOMServer.renderToString 를 수행하여 실제로 HTML로 렌더링합니다. 이제 모든 종속성이 해결되었기 때문에 동기화됩니다.

react-baconjs : render-to-html.js 에서 이 접근 방식을 취했습니다. 이러한 접근 방식을 권장하는 다른 문제에서 @gaearon이 작성한 댓글에서 영감을 받았습니다.

@steve-tailor 예, 작동합니다. 이것은 또한 모든 React 앱에서 작동하는 보다 일반적인 목적의 솔루션인 react-frontload 에서 사용하는 해결 방법입니다.

본질적으로 말했듯이 동기 렌더링 논리를 두 번 실행하고 첫 번째 렌더링에서 적중한 모든 데이터 로드 약속이 두 번째를 실행하기 전에 해결될 때까지 대기하여 비동기 렌더링을 가장하는 것입니다.

분명히 약간의 낭비가 있음에도 불구하고 충분히 잘 작동합니다(첫 번째 렌더의 출력은 단지 약속 그 이상이며, 그냥 버려지는 실제 HTML이기도 합니다). 진정한 비동기 서버 렌더링이 React로 만들어지면 놀랍습니다.

@davnicwil 잘했어! 특정 비동기 SSR 솔루션을 일반화하는 것에 대해 생각했습니다. react-frontload가 무제한 비동기 깊이를 처리합니까? "두 번"이라고 말했기 때문에 묻는 것입니다.

@steve-tailor 건배! 예, 깊이가 트리의 구성 요소 깊이를 의미한다면 무제한입니다. 이를 통해 컴포넌트 자체(고차 컴포넌트 포함)에서 데이터 로드 함수를 선언할 수 있으며 첫 번째 렌더링에서 해당 함수가 발생하면 실행되고 약속이 수집됩니다.

작동하지 않는 것은 데이터를 비동기식으로 로드하는 추가 하위 구성 요소가 있는 경우입니다. 이 구성 요소는 타당한 경우 결과에 따라 동적으로 렌더링됩니다. 그것은 단지 앱이 이런 종류의 중첩이 없도록 구조화되어야 한다는 것을 의미합니다. 실제로 제가 발견한 이것은 엄청난 제한이 아닙니다. 사실 중첩된 비동기 논리는 직렬 요청과 더 긴 대기 시간을 의미하는 반면 평면화는 병렬 요청을 의미하기 때문에 여러 면에서 UX 측면에서 더 좋습니다 .

즉, 중첩 문제(실제로 이 전체 비동기 서버 렌더링 문제)는 가까운 장래에 React에 포함될 Suspense 항목으로 해결될 수 있습니다. 🤞

참고로 이 작업을 시작했습니다.

https://reactjs.org/blog/2018/11/27/react-16-roadmap.html#suspense -for-server-rendering

멋지다 @gaearon!

@davnicwil react-baconjs 은 무제한 깊이를 지원합니다.

@gaearon 나는 이것이 관찰 가능한 발사 JSX를 반응 구성 요소로 변환할 수 있도록 생성 구독에서 관찰 가능한 지원을 가능하게 하는지 궁금합니다.

이 기능을 갖고 싶은 이유는 두 가지입니다. 먼저 내 앱에서 상태는 웹 작업자에 저장됩니다. 따라서 구성 요소가 요구하는 해당 상태의 비트를 검색하는 것은 비동기 작업이지만 5ms 정도 걸리며 React가 데이터를 기다리는 동안 아무 것도 렌더링하는 것은 의미가 없습니다. 둘째, 지금 당장은 옵저버블을 컴포넌트로 변환하는 보편적인 방법이 없습니다. 옵저버블이 첫 번째 값을 동기적으로 방출하면 그 값을 얻기 위해 구독하고, 구독을 취소하고, 변경 사항을 수신하기 위해 다시 구독합니다(즉, Replay create-observable 문서의 주제 예). 그리고 비동기식으로 첫 번째 값을 내보내는 경우 처음에는 null을 렌더링하고 변경 사항을 수신 대기합니다.

@steve-taylor react-frontload는 이제 1.0.7 릴리스와 함께 구성 요소 중첩의 무제한 깊이도 지원합니다.

이 라이브러리가 이 스레드를 시작하는 일부 사람들에게 유용하기를 바랍니다. 최소한의 통합 노력으로 클라이언트/서버 렌더에서 작동하는 비동기 데이터 로딩 솔루션을 찾고 있다면 확인해야 합니다.

우리는 앱이 React Hooks로 빌드될 때 이 문제를 겪었고 이를 해결하기 위해

그러나 우리는 여전히 공식 솔루션을 기대하고 있습니다. react-frontload에서 말했듯이 현재 렌더링이 시작되면 비동기 데이터 로드가 발생할 때까지 기다릴 수 있는 기본 제공 방법이 없습니다.