React: [우산] 서스펜스를 풀어

unstable_AsyncMode 노출(아마도?)

이거 이미 노출 된거 아님?

unstable_ 제거를 의미했습니다.

이름 없는 코드 분할 라이브러리의 오픈 소스를 기대합니다 💯

[우산]은(는) 무슨 뜻인가요?🤔☂️

즉, 여러 프로젝트/패키지/도구에 영향을 미치는 기능입니다.

@ghoullier 알겠습니다 , 정말 감사합니다!

@acdlite , 가장 잘 준비하는 방법에 대한 질문입니다. 어떤 종류의 타임라인도 요구하거나 기대하지 않고 궁금합니다.

현재 이러한 기능이 React 16에 포함되고 16.3에 포함된 새로운 Context API와 같이 점진적으로 쉽게 채택할 것으로 예상하십니까?

아니면 React를 v17로 밀어붙이고 채택하려면 더 많은 작업이 필요하다고 생각하십니까?

귀하의 목록에 있는 거의 모든 항목과 크게 교차하는 로드맵을 작업 중이고 이를 가장 잘 처리하는 방법을 찾기 위해 노력하고 있기 때문에 질문합니다.

또한 가장 잘 준비하는 방법에 대한 팁이 있습니까?

(이 질문에 대한 답변이 다른 곳에서 누락된 경우 사과드립니다)

@JedWatson 의 질문에 다른 질문 추가:

• 또한 안정적인 릴리스에 대한 타임라인을 얻을 필요가/없을 것으로 예상되지만, 새로운 프리릴리즈를 얻는 것이 가능/유용할까요? (AFAIK의 최신 릴리스는 2월부터 16.4.0-alpha.0911da3 입니다.)

감사합니다! ❤️

IMO, 그들은 상륙하기 전에 이전과 같은 블로그 게시물을 제공할 것입니다.

그리고 큰 변화가 없기 때문에 너무 많이 준비할 필요는 없다고 생각합니다(예: redux fetch with suspense와 같이 현재 관행과 다르게/충돌할 수 있는 많은 기능이 있지만 codemod 또는 쉬운 캡슐화가 있을 것입니다. 이를 위해 fb에는 3W+ 구성 요소가 있습니다. 그리고 @acdlite (ZEIT의 @gaearon (아이슬란드의 클라이언트 서스펜스에 대해)에 대한 이야기를 보면 너무 많이 걱정할 필요가 없고 침략적이지 않다는 것을 알게 될 것입니다.

그건 그렇고, 저장소에서 'Umbrella' 키를 검색하면 #8830 및 #12152와 같은 더 많은 정보를 찾을 수 있습니다.

AFAIK의 최신 릴리스는 2월의 16.4.0-alpha.0911da3입니다.

IIRC, 이것은 오작동입니까?

@JedWatson 이 댓글은 개발자가 애플리케이션이 비동기식으로 안전한지 확인하기 위해 수행해야 하는 작업을 이해

저는 페이스북에서 서스펜스 모듈과 새로운 API를 출시하기 위해 노력하고 있습니다. @acdlite 가 다른 Facebook 에서의 경험에 대한 생각을 공유하고 @JedWatson의 몇 가지 질문에 답하고 싶습니다.

현재 이러한 기능이 React 16에 포함되고 16.3에 포함된 새로운 Context API와 같이 점진적으로 쉽게 채택할 것으로 예상하십니까?

React 16 또는 17과 함께 올지 모르겠습니다. React 팀에 따르면 올해 말 이전에 출시될 가능성이 높으며 이는 Facebook에서 얼마나 잘 실행되고 관련 API가 준비되어 있는지 또는 아니다. 그러나 코드 면에서는 채택하기 쉬울 것이라고 말씀드리게 되어 기쁩니다. 왜냐하면 우리는 facebook에서 꽤 오랫동안 실험을 해왔기 때문입니다. 서스펜스 기능은 기존 코드베이스에서 계속 작동합니다. 그러나 (비동기 렌더링과 같은) 추가 변경을 통해 새로운 기능이 제공하는 더 많은 보너스를 얻게 됩니다.

(오늘 작성된 코드 측면에서 향후 React에 대한 이러한 개선 사항과 호환되기를 원하는) 폴리필/기술 등을 가장 잘 준비하는 방법에 대한 팁이 있습니까?

나는 마이그레이션이 다소 점진적이고 점진적이라고 말하고 싶습니다. @NE-SmallTown이 말했듯이 우리는 주요 변경 사항을 도입하고 싶지 않습니다. 그것은 또한 우리가 너무 큰 코드베이스를 가지고 있기 때문에 페이스북에 롤아웃하는 것도 고통스러울 것입니다. 그러나 지금까지는 롤아웃이 원활했으며 추가 변경을 수행할 필요가 없습니다.

@JedWatson

현재 이러한 기능이 React 16에 포함되고 16.3에 포함된 새로운 Context API와 같이 점진적으로 쉽게 채택할 것으로 예상하십니까?

증분. 항상 점진적으로 :) 그렇지 않으면 Facebook에서 이것을 배송할 수 있는 방법이 없습니다.

내가 기대하는 것은 다음과 같습니다.

| | 클라이언트 | 서버 측 렌더링 |
|-----|----------------------------|-- ------------------------------------------|
| 서스펜스 | 어디서나 작동* | 기존 서버 렌더러와 동일한 제약 조건 |
| 비동기 렌더링 | <AsyncMode> 를 사용하여 선택 | 기존 서버 렌더러와 동일한 제약 조건 |

*동기화 모드에서 delayMs 는 항상 0 입니다. 자리 표시자가 즉시 표시됩니다.

Suspense는 기존 구성 요소를 변경하지 않고도 작동합니다. 한때 우리는 <StrictMode> 호환성이 필요할 수 있다고 생각했지만 내부 테스트 중에 엄격 모드로 업그레이드하는 가장 좋은 방법 중 하나는 Suspense를 사용하는 것임을 발견했습니다. 닭고기 달걀 딜레마. 그래서 우리는 엄격 모드 밖에서도 작동하도록 하는 방법을 찾았습니다.

따라서 사용자는 비동기 렌더링으로 마이그레이션할 준비가 되기도 전에 Suspense로 마이그레이션을 시작할 수 있습니다. 그런 다음 하위 트리가 준비되면 <AsyncMode> 로 래핑하여 옵트인할 수 있습니다.

그러나 새 앱의 경우 이야기가 다릅니다. 기본적으로 비동기식으로 전환합니다. 비동기 전용인 새로운 루트 API( ReactDOM.render 대체)를 소개합니다.

많은 타사 프레임워크(Redux, Apollo, React Router...)가 비동기 모드에서 제대로 작동하지 않을 수 있는 초기 릴리스 이후 어색한 기간이 있을 것입니다. 그것은 한동안 입양에 지장을 줄 수 있습니다. 그러나 아이디어는 새로운 기능이 너무 매력적이어서 라이브러리가 비동기 호환 대안으로 적응하거나 대체하는 데 오랜 시간이 걸리지 않을 것이라는 것입니다.

또한 가장 잘 준비하는 방법에 대한 팁이 있습니까?

모든 것을 <StrictMode> 감싸고 경고가 없는지 확인하십시오. 릴리스가 가까워지면 더 자세한 마이그레이션 가이드가 제공됩니다.

많은 타사 프레임워크(Redux, Apollo, React Router...)가 비동기 모드에서 제대로 작동하지 않을 수 있는 초기 릴리스 이후 어색한 기간이 있을 것입니다.

Apollo는 어색하지 않습니다. 준비가 되어 있습니다! 🕺😳

진심으로 우리는 :heart: 모든 것이 React이므로 초기 릴리스에서 이러한 변경 사항에 부합하는지 확인하는 것은 최우선 순위일 뿐만 아니라 매우 흥분되는 일이기도 합니다! 이 @acdlite에 대한 모든 놀라운 작업에 감사드립니다!

Redux 팀이 React-Redux에 대한 비동기 호환성 작업을 하고 있다고 말하겠습니다.

https://github.com/reduxjs/react-redux/issues/950 에서 잠재적 로드맵을 제시했습니다. TL;DR:

• React-Redux 5.1은 경고 없이 <StrictMode> 와 함께 작동하기를 바랍니다(현재 PR: https://github.com/reduxjs/react-redux/pull/980 ).
• 6.0은 새로운 컨텍스트 API를 사용하기 위해 내부 재작성, 참조 전달 및 기타 변경 사항을 추가하지만 가능한 한 현재 공개 API(예: <Provider> 및 connect() ). 이것이 비동기 렌더링에서 얼마나 잘 작동하는지 살펴보고 앞으로의 최선의 경로를 알아낼 것입니다. (나의 이전 개념 증명 PR은 https://github.com/reactjs/react-redux/pull/898 에 있지만 5.1 작업에서 배운 다른 교훈을 기반으로 다시 실행할 것입니다.) 이 릴리스에는 새로운 컨텍스트가 필요하고 아직 출시되지 않은 "라이프사이클 메서드에서 컨텍스트 읽기" PR이 필요하기 때문에 최소한 React 16.5가 필요합니다.
• 그 후에 다른 React-Redux API에 대한 아이디어를 얻을 수 있습니다(예, 예, 여기에는 렌더링 소품, 사람이 포함될 수 있음).

우리는 WIP에 더 많은 관심을 가져줘서 고맙고 사람들이 Redux를 React Suspense 및 비동기 렌더링과 함께 사용하는 방법에 대해 더 많은 피드백과 토론을 제공하여 사용 사례가 제대로 다루어지도록 할 수 있기를 바랍니다. 우리는 또한 정확히 어떤 제약 조건으로 작업해야 하는지에 대해 React 팀과 더 많은 토론을 하기를 희망하며, 모든 문제에 대해 어떤 문제를 해결해야 하는지 확인할 수 있는 샘플 앱을 얻을 수 있다면 도움이 될 것입니다. 이것은 올바르게 작동합니다.

비동기 렌더링 및 서스펜스 출시 기대

@acdlite 또한 서스펜스 및 비동기 렌더링에 대한 질문입니다.
내 질문은 그들이 도입되고 새로운 버전의 react로 앱을 작성하기 시작하면 반응 API와 반응에서 사람들이 코딩하는 방식도 변경된다는 것을 의미합니까? (서스펜스 및 비동기 렌더링 기능을 사용할 계획이 없더라도?)

나는 서스펜스 및 비동기 렌더링으로 반응 코드를 작성하는 것이 더 까다로울 수 있다고 가정하고(일부 새로운 API 또는 기타 제약으로 인해) 필요하지 않은 사람들을 위해 왜 새로운 방식으로 반응을 사용하도록 강제합니까? 그리고 그들이 지금처럼 반응하는 방식으로 코딩하는 것을 허용하지 않습니까?

나는 서스펜스가 있는 반응 코드를 작성하는 것이 더 까다로울 수 있다고 가정합니다.

제 강연 후반부를 볼 기회가 있으셨나요? 저는 그 반대라고 말하고 싶습니다. 데이터 가져오기에 서스펜스를 사용하는 것이 다른 어떤 것(Redux, 로컬 상태 또는 기타 라이브러리 포함)보다 훨씬 덜 까다롭습니다.

@gaearon 안했어요. 나는 이론상으로 더 말을 하고 있었다. 반응을 알고 있는 사람들이 이미 있다고 상상해 보십시오. 사람들이 비동기 렌더링 및 서스펜스 기능이 필요하지 않다면 왜 강제로 "새로운" 반응을 배우게 합니까? 특히 "새로운" 반응이 사용하기 더 어렵다면? 하지만: 저는 정보가 부족하여 "더 까다로운" 부분에 대해 잘못 말할 수 있습니다. 저는 단지 제 생각을 공유하고 있습니다. :).

어떤 면에서는 앱의 10%가 Suspense 및 비동기 렌더링 기능을 필요로 하는 경우 다른 90%의 경우 사람들이 "새로운" 반응을 배우도록 강요하는 이유는 무엇입니까? 하지만 아직 서스펜스 및 비동기 렌더링에 대한 정보를 많이 수집하지 않았기 때문에 내가 틀릴 수도 있습니다.

내 데모를 아직 보지 않았다면 대화가 어려울 것이라고 생각합니다.

명확히 하자면 "새로운 React" 는 없으며 이러한 기능은 기존 패턴을 깨뜨리지 않습니다. 그들은 첨가제입니다. 이러한 기능을 사용하기 위해 완전히 다른 방식으로 코드를 작성할 필요는 없습니다. 일부 기능은 최신 수명 주기 방법 을 합니다 .

이것이 귀하의 우려와 직접적인 관련이 없지만 "사용하기가 더 까다롭다"는 데 동의하지 않습니다. 나는 서스펜스가 현재 존재하는 다른 어떤 로딩 메커니즘보다 사용하기 훨씬 간단하다고 생각합니다. 그것이 내가 그것에 대해 너무 흥분되는 이유입니다. 그러나 원하지 않는 경우 새 기능 을 사용할 필요가 없습니다. 오래된 패턴은 계속 작동합니다.

내 이야기를 시청 하는 것이 좋습니다. 이러한 기능이 실제로 작동하는 것을 보면 훨씬 더 이해가 될 것이라고 확신합니다.

@gaearon

모든 오래된 패턴이 계속 작동합니다.

피드백 주셔서 감사합니다. 네, 그렇게 생각했습니다. 사람들이 그런 기능을 필요로 하지 않는다면 그 기능이 추가되기 전에 사용하던 방식으로 쓸 수 있어야 한다고 생각합니다.

행운을 빕니다.

Hey Dan(@gaearon), 헛소리는 아니지만 알아내고 싶습니다. 위에서 당신은 말했습니다.

그러나 원하지 않는 경우 새 기능을 사용할 필요가 없습니다. 오래된 패턴은 계속 작동합니다.

"이전" React에서 했던 것과 같은 방식으로 새로운 React에서 코딩할 수 있다는 것을 암시하는 것은 무엇입니까?

그러나 여기서 bvaughn은 getDerivedStateFromProps(또는 componentWillReceiveProps)가 하나의 업데이트에 대해 여러 번 호출될 수 있으므로 내부 데이터를 가져오지 않는 그의 솔루션을 말합니다.

그래서 내 질문은 결국 우리가 이전과 똑같은 방식으로 새로운 React를 사용할 수 없는 것 같습니까? 현재 반응하는 componentWillReceiveProps의 AFAIK는 한 번의 업데이트에 대해 여러 번 호출되지 않기 때문에 그렇지 않습니까?

@giorgi-m : 예, 수명 주기 방식이 변경되고 있지만 요점은 Suspense 자체가 옵트인 기능이라는 것입니다. 기존의 모든 React 렌더링 방법과 React의 렌더링 동작은 그대로 작동합니다. 그러나 _if_ <AsyncMode> 태그를 앱의 일부에 추가하여 선택하고 _그리고_ 비동기 데이터 요구 사항을 표시하기 위해 Suspense의 접근 방식을 사용하기 시작하면 _그때_ 활용할 수 있습니다. 코드베이스에 추가하지 않으면 아무 일도 일어나지 않습니다.

@giorgi-m componentDidUpdate 는 componentWillReceiveProps 또는 getDerivedStateFromProps 대신 사용해야 합니다.

@markerikson 그래서 당신은 bvaughn이 여기 에서 말한 대로 _getDerivedStateFromProps_가 한 업데이트에 대해 여러 번 호출될 수 있지만 <AsyncMode/> 활성화하지 않은 경우 반드시 그런 것은 아닙니다.
(이러한 질문을 해서 죄송합니다. 때때로 저에게 나타나며 모든 내용을 다룰 리소스를 찾지 못했습니다).

추신. bvaughn은 또한 연결된 스레드에서 선택 사항을 언급하지 않았으므로 내 의심이 제기되었습니다.

비동기 업데이트를 대기열에 추가하는 방법(예: 렌더러별 unstable_deferredUpdates() 아닌 클래스 구성 요소의 경우 deferSetState() unstable_deferredUpdates() )을 핵심 체크리스트에 추가해야 합니까?

내 이해에서 async mode Fiber에 대한 모든 업데이트는 비동기식이므로 이론상 deferSetState() 가 불필요합니다. 그러나 unstable-async/suspense 데모 는 동기 업데이트와 비동기 업데이트를 혼합하고 async 모드("범용" 구성 요소의 경우)에서 이를 어떻게 수행할 수 있는지 잘 모르겠습니다.

타임슬라이싱 우산 체크리스트에 있습니다.

컴포넌트 유형으로 Promise 지원

이와 관련하여 다음이 있는 경우:

const PromiseType = new Promise(() => {})
class A extends Component {
    componentDidMount() {}
    componentDidUpdate() {}
    render() {
        return <div><PromiseType></PromiseType></div>
    }
}

componentDidMount 및 componentDidUpdate 수명 주기가 호출되는 시점에 대한 경험적 방법이 있습니까?

1. 모든 자식이 해결되었을 때(약속 포함), 이 경우 약속이 해결되지 않은 경우 호출되지 않는다는 의미는 무엇입니까?
2. 모든 직접 호스트 자식이 렌더링되면?

@thysultan : componentDidMount 및 componentDidUpdate 는 UI 트리가 완전히 렌더링되어 DOM에 적용된 커밋 단계에서 호출됩니다.

따라서 Suspense에 대한 나의 이해를 바탕으로 답은 A 인스턴스가 실제로 마운트되지 않을 것이라는 것입니다. PromiseType _did_ 가 해결되었지만 추가 자손 중 하나가 절대 해결되지 않는 약속을 기다리려고 시도하면 다시는 마운트되지 않습니다. 따라서 cDM 및 cDU 는 이러한 예에서 실행되지 않습니다.

(누군가 내 가정이 잘못된 경우 자유롭게 수정해 주세요. :) )

예, componentDidMount 또는 componentDidUpdate 는 전체 트리 가 해결된 후에만 실행되는 커밋 단계 에서만 실행됩니다. 이 트리에는 명시적으로 배치한 일부 자리 표시자가 포함될 수 있습니다(충분히 오래 기다린 후에도 그 안의 무언가가 여전히 일시 중단되는지 여부에 따라 다름) — 하지만 주위에 자리 표시자가 없는 자식을 명시적으로 렌더링하면 다음과 같이 될 수 없습니다. "준비되지 않은" 상황입니다.

나는 이것을 가지고 놀 수 있기를 정말로 고대하고 있습니다. (심지어 당신이 아직 월드 와이드 웹에 이것의 작동 버전을 올리지 않았다는 것을 알아내기 위해 많은 소스 코드를 탐색했습니다).

이 릴리스를 돕기 위해 우리가 할 수 있는 일이 있습니까? :디

플레이하고 싶다면 마스터에서 컴파일할 수 있습니다. fixtures/unstable-async/suspense 지침 보기

@gaearon 이것이 현재 상태의 클라이언트 측에만 있는 것이 맞

편집, 답을 찾았습니다. 범용 앱용 SSR에서 Suspense를 사용하고자 하는 다른 사람을 위한 것입니다. 현재로서는 이것이 클라이언트 측임을 알려주는 Dan의 이 댓글 을 찾았습니다. 그러나 그 의견은 SSR에 대한 가능한 의미에 대해 이야기하는 https://www.youtube.com/watch?v=z-6JC0_cOns 도 가리킵니다.

우리는 실제로 SSR 사건과 관련된 몇 가지 작업을 곧 시작합니다.

저가형 모바일 장치에서 실행되는 비동기 React 앱에서 이 시나리오를 상상해 보십시오.

1. CPU를 모두 사용하는 외부 광고 로딩이 있습니다(😓)
2. 사용자가 링크를 클릭하면 라우터가 새 렌더링을 트리거합니다.
3. React는 비동기 모드이므로 Chrome/Safari에서 CPU 사용 권한을 부여할 때까지 기다리지만 광고는 3초 동안 계속 로드됩니다.
4. 사용자가 앱이 작동하지 않는다고 생각함

이 문제는 Suspense에 대해 논의된 것과 동일한 <Placeholder> 기술을 사용하여 피할 수 있습니다. 예를 들어 1초 후에 스피너가 표시됩니다.

이 시나리오가 고려되었습니까? 느린 비동기 렌더링에 <Placeholder> 작동합니까?

@luisherranz 이를 방지하는 두 가지 메커니즘이 있습니다.

1. React에는 모든 업데이트와 관련된 마감일이 있습니다. 클릭 및 이와 같은 기타 상호작용으로 인한 업데이트는 명시적으로 더 긴 기한을 선택하지 않는 한 ~150ms 이내에 플러시되어야 합니다(예: 필수적이지 않은 업데이트의 경우). 따라서 React는 무언가가 스레드를 잡아먹는 경우 동기적으로 플러시를 강제 실행합니다.

2. React는 실제로 더 이상 requestIdleCallback 하지 않습니다. 왜냐하면 실제로 브라우저는 스케줄링에 대해 충분히 공격적이지 않기 때문입니다. 정확한 일정 접근 방식도 시간이 지남에 따라 변경될 수 있지만 이것은 확실히 우리가 관심을 갖고 있는 것입니다.

빠른 답변에 감사드립니다. Dan.

1. React에는 모든 업데이트와 관련된 마감일이 있습니다.

엄청난. 테스트할 수 있는 API가 이미 있습니까?

1. React는 실제로 더 이상 requestIdleCallback을 사용하지 않습니다. 왜냐하면 실제로 브라우저는 예약에 대해 충분히 공격적이지 않기 때문입니다.

그것은 우리가 실험한 것이기도 합니다. 때때로 외부 광고가 있고 twitter 또는 youtube에서 퍼가는 복잡한 앱에서 requestIdleCallback 가 호출되고 렌더링이 완료될 때까지 몇 초가 걸릴 수 있습니다. 그래서 👍.

BTW, 우리에게는 첫 번째 답변과 관련된 또 다른 사용 사례가 있습니다. 우리는 두 개의 오프셋으로 지연 로드를 사용하려고 합니다. 첫 번째는 비동기 렌더링을 트리거하고 두 번째는 비동기가 완료되지 않은 경우 동기화 렌더링을 트리거합니다. 이 같은:

1. 사용자가 아래로 스크롤하면 무거운 요소(예: 블로그의 다음 게시물)에서 1200픽셀에 있습니다.
2. 첫 번째 오프셋은 다음 게시물의 비동기 렌더링을 트리거합니다.
3. 사용자는 계속 아래로 스크롤하고 다음 게시물의 600px에 있습니다.
4. 두 번째 오프셋 트리거: 비동기 게시물이 완료되면(componentDidMount 호출) 아무 일도 일어나지 않지만 그렇지 않은 경우 전체 게시물의 동기화 렌더링을 트리거합니다.

따라서 시간 대신 두 번째 트리거로 플러시를 제어하고 싶습니다. 말이 되나요? 가능할까요?

테스트할 수 있는 API가 이미 있습니까?

마스터를 의미하는지 아닌지(비동기 모드는 npm 릴리스에서 공식적으로 사용할 수 없음) 확실하지 않지만 만료 시간은 모든 업데이트에 자동으로 할당됩니다. 클릭과 같은 이벤트의 경우 프로덕션 모드에서 ~150ms입니다. 특별히 불안정한 API를 원하는 경우 지연된(더 긴) 업데이트를 선택할 수 있지만 설정할 수는 없습니다.

따라서 시간 대신 두 번째 트리거로 플러시를 제어하고 싶습니다. 말이 되나요? 가능할까요?

네 가능합니다. 여기에서 다음과 같은 메커니즘을 설명했습니다. https://github.com/oliviertassinari/react-swipeable-views/issues/453#issuecomment -417939459.

마스터를 의미하는지 아닌지 확실하지 않습니다(비동기 모드는 npm 릴리스에서 공식적으로 사용할 수 없음)

예, <unstable_AsyncMode> , flushSync 및 unstable_deferredUpdates 와 함께 npm 패키지를 사용하고 있습니다.

npm에 대한 이러한 변경 사항으로 알파/베타 버전 출시를 시작하십시오! 🙏

네 가능합니다. 나는 여기에 다음과 같은 메커니즘을 설명했습니다: oliviertassinari/react-swipeable-views#453 (comment).

훌륭한. unstable_deferredUpdates 사용하는 현재 구현보다 훨씬 낫습니다. :)

<div hidden> 사용하기 시작할 때까지 기다릴 수 없습니다. 당신은 놀라운 일을하고 있습니다.

@luisherranz 조심하세요. 그런 것들은 불안정합니다. 버그가 있거나 매우 비효율적일 수 있습니다(예: 중요한 최적화 - "재개" - 아직 구현되지 않음). 새로운 schedule 모듈( schedule.unstable_scheduleWork )을 위해 unstable_deferredUpdates 도 제거합니다.

네, 우리는 앱의 작은 부분에만 사용하고 집중적으로 테스트하고 있지만 지금까지는 너무 좋습니다 :)

주제와 다를 수 있음:
requestIdleCallback 는 초당 20번만 호출됩니다. 6x2 코어 Linux 컴퓨터의 Chrome에서는 UI 작업에 실제로 유용하지 않습니다.
requestAnimationFrame 는 더 자주 호출되지만 이름이 제안하는 작업에만 해당됩니다.

이러한 이유로 requestIdleCallback 사용을 중단했습니다.

requestIdleCallback 대신 무엇을 사용하고 있습니까?

@TejasQ https://github.com/facebook/react/tree/master/packages/scheduler

아, 물론입니다. 바보 나. 스케줄러 모듈이 requestIdleCallback 대신 후드 아래에서 사용하는 브라우저 API가 무엇인지 궁금합니다. 질문을 더 명확하게 제시했어야 했습니다. 😂

오, 찾았습니다.
https://github.com/facebook/react/blob/eeb817785c771362416fd87ea7d2a1a32dde9842/packages/scheduler/src/Scheduler.js#L212 -L222

그것은 다음 단계의 멋진 것입니다.

안녕,

Suspense를 이해하려고 하는 동안 Suspend 구성 요소 😳😱를 사용할 때 앱의 어떤 부분이 실제로 "일시 중단"되었는지 전혀 모른다는 것을 깨달았습니다.

다음 예에서 나는 기대 Title 즉시 볼 수 있도록 Spinner 1000MS 이후 UserData ~ 2000ms (해당 구성 요소로 "로드"데이터가 2000ms 소요) 후.
그러나 내가 본 것은 Title 가 1000ms 후에 Spinner 와 함께 처음 나타납니다.

// longRunningOperation returns a promise that resolves after 2000ms
const UserResource = createResource(longRunningOperation);

function UserData() {
  const userData = UserResource.read(cache, "Lorem Ipsum");
  return <p>User Data: {userData}</p>;
}

function Spinner() {
  return <h1>Fallback Loading Spinner</h1>;
}

function Title() {
  return <h1>Hello World</h1>;
}

function App() {
  return (
    <React.Fragment>
      <Title />
      <Suspense maxDuration={1000} fallback={<Spinner />}>
        <UserData />
      </Suspense>
    </React.Fragment>
  );
}

unstable_createRoot(document.getElementById("mount")).render(<App />);

(React 16.6.0-alpha.8af6728을 사용하는 완전한 예제는 여기 코드샌드박스

Title 즉시 표시하고 애플리케이션의 다른 부분만 "일시 중지"하는 방법이 있습니까? 아니면 내가 완전히 Suspense를 잘못 이해 했습니까? (이런 종류의 질문을 하는 더 좋은 방법이 있다면 알려주세요)

감사 해요!

안녕하세요 @nilshatmann입니다! 좋은 질문입니다!

제목을 즉시 표시하고 응용 프로그램의 다른 부분만 "일시 중지"하는 방법이 있습니까?

내가 올바르게 이해했다면 Title 즉시 표시하고 다른 항목만 "일시 중단"하기 위해 이 예제 에서와 같이 Title 를 DOM에 플러시하기 전에 React에 _기다리지 말라고_ 명시적으로 알려야 합니다. <Suspense maxDuration={0}> 에서 즉시 렌더링될 것으로 예상되는 부분을 래핑하여 애플리케이션의 일부입니다.

기본 저수준 스케줄러 역학 때문에 이것이 사실이라고 생각합니까? 나는 또한 이것을 더 잘 이해하고 싶지만 지금으로서는 당신의 문제를 해결해야 합니다.

그곳에서 실제로 무슨 일이 일어나고 있는지 들으니 흥분됩니다.

(이런 종류의 질문을 하는 더 좋은 방법이 있다면 알려주세요)

있는지 잘 모르겠습니다. 😄 확실히 알 것 같습니다. 질문 주셔서 감사합니다!

@TejasQ 내 브라우저에서 예제를 로드하면 폴백 스피너가 즉시 렌더링됩니다. 1000ms 후에 불러와야 하는 것 아닌가요?

@TejasQ 답변 감사합니다. 하지만 @karlhorky 가 맞습니다. 이제 스피너가 즉시 나타납니다.

좋아! 나는 그것을 놓쳤다. 나는 시도했다. 😂 다시 한 번 살펴보고 다시 연락드리겠습니다. 뭔가 놓친 게 틀림없어. 🤷‍♂️

~업데이트: 여기에서 알아내려고 하고 있고 실시간으로 함께 하고 싶은 사람이 있으면 협업할 수 있습니다.~

두 번째 업데이트: @philipp-spiess와 나는 그것을 보았고 나는 정말로 당황했습니다. 나는 아직도 그것을 이해하지 못한다. 이 시점에서 이것이 실제로 unstable_ 및 알파 기능이기 때문에 버그인지, 아니면 단순히 내가 보지 못하는 항목인지 확실하지 않습니다.

두 경우 모두 핵심 팀이 유용한 답변을 제공하거나 귀하의 질문을 사용하여 React를 더 나은/더 접근하기 쉽게 만들 수 있을 것 같습니다.

그들이 무슨 말을 해야 하는지 봅시다. 😄 지적해 주셔서 감사합니다, @nilshatmann!

이것은 React v16.6의 일부로 출시되었습니까? 블로그 게시물 은 Suspense를 사용하는 예제 코드를 보여줍니다.

import React, {lazy, Suspense} from 'react';
const OtherComponent = lazy(() => import('./OtherComponent'));

function MyComponent() (
  <Suspense fallback={<div>Loading...</div>}>
    <OtherComponent />
  </Suspense>
);

이것은 React v16.6의 일부로 출시되었습니까?

지연 로딩 사용 사례만 동기화 모드에서만 가능합니다. 동시 모드는 여전히 WIP입니다.

@nilshatmann

다음 예에서는 Title이 즉시 표시되고 1000ms 후에 Spinner가 표시되고 ~2000ms 후에 UserData가 표시될 것으로 예상합니다(해당 구성 요소에 대한 데이터를 "로드"하는 데 2000ms가 소요됨).

maxDuration 가 하는 일에 대해 약간 혼란스러워 하시는 것 같습니다. 이것은 새로운 멘탈 모델이지만 아직 문서화할 시간이 없었습니다. 따라서 동시 모드가 안정적인 릴리스가 될 때까지 한동안 계속 혼란스러울 것입니다.

후크 제안을 발표한 것을 축하합니다. 팀과 공유하고 싶은 것이 있습니다. 얼마 전에 Suspense와 유사한 기능을 가진 React Async 라는 구성 요소를 출시했습니다. 기본적으로 Promise 확인을 처리하고 isLoading, startedAt와 같은 메타데이터 및 reload 및 취소와 같은 메서드를 모두 선언적 API로 제공합니다( useAsync 후크 가 진행

이제 내 주요 관심사는 이것이 Suspense와 통합되는 방법입니다. 대부분의 경우 React Async의 Suspense API를 사용하고 사용자에게 친숙하고 간단한 React Async API를 제공하는 동시에 Suspense의 일정 기능을 무료로 제공할 수 있습니다. 내가 본 바에 따르면, React Async API가 더 추상적인 Suspense API에 비해 더 합리적이고 접근하기 쉽다고 생각합니다. 본질적으로 React Async는 사용 사례의 약간 더 작은 하위 집합에서 작동하는 보다 구체적인 API를 제공하려고 합니다.

React Cache 라이브러리에 대해 알고 놀랐습니다. React Async의 경우 의도적으로 캐시 메커니즘을 포함하지 않았지만 바닐라 Promise를 처리하기로 결정했습니다. 그 위에 캐싱을 추가하는 것은 상당히 쉽습니다.

마지막으로 사용자 지정 후크에서 Suspense 기능에 액세스하는 것에 대해 우려하고 있습니다. 서스펜스는 여러 내장 구성 요소에 크게 의존하는 것 같으므로 후크에서 이러한 구성 요소를 사용하는 것이 불가능합니다(제 생각에는?). 서스펜스 후크가 있습니까? 아니면 둘을 통합하는 다른 방법이 있습니까?

여보세요. Suspense/Lazy로 코드를 테스트하려면 어떻게 해야 합니까?
이제 renderer.create(...)toTree() throws
"toTree()는 태그가 13인 노드를 처리하는 방법을 아직 모릅니다."

Suspense 의 소품 maxDuration 이 동기화 및 동시 모드가 아닌 Concurrent Mode 에서만 사용되는 이유입니다. 아무도 설명을 도와줄 수 있습니까?

(지금 당장은) Concurrent Mode 가 이 트리를 커밋하기 전에 보류 상태로 둘 수 있는 기간을 의미합니다. 이는 타임 슬라이싱 마감 기한을 효과적으로 제어하며 Sync 모드에서는 타임 슬라이싱이 존재하지 않습니다. 트리를 커밋하기 전에 기다리면 반드시 커밋이 ... 동기화되지 않습니다.

저는 데이터 가져오기를 위해 내부 응용 프로그램에서 Suspense를 사용해 왔으며 아직 데이터 가져오기에 사용할 수 없는 이유를 매우 빨리 발견했습니다.

그러나 결국 데이터를 가져오는 데 사용됩니다. 아마도 캐시 공급자를 제외하고 API가 크게 변경될 것 같지 않다는 점을 감안할 때 데이터를 가져온 후 수정해야 하는 경우 Suspense는 어떻게 작동합니까?

예를 들어, 여기 내 응용 프로그램의 정말 끔찍한 후크가 있습니다.

function useComponentList(id) {
  const incomingComponents = useSuspenseFetch(
    React.useCallback(() => getComponentAPI().listComponents(id), [id])
  )

  const map = React.useMemo(
    () =>
      Map(
        (incomingComponents || []).map(component => [component.id, component])
      ),
    [incomingComponents]
  )

  return useCacheValue(map)
}

이 후크:

1. 주어진 끝점에서 주어진 콜백을 사용하여 데이터를 가져옵니다.
2. 해당 데이터를 ImmutableJS Map으로 변환 - 잠재적으로 비용이 많이 들기 때문에 작업을 메모합니다.
3. useCacheValue 래핑된 지도를 반환합니다. 이는 특히 어색한 부분입니다.

useCacheValue 는 다음과 같습니다.

export default function useCacheValue(value) {
  const [state, setState] = React.useState(value)
  React.useEffect(() => {
    setState(value)
  }, [value])

  return [state, setState]
}

value 변경(데이터를 다시 가져왔음을 나타냄)에 응답하지만 사용자가 해당 상태의 반응 앱 표현을 수정할 수 있도록 하는 후크라는 아이디어가 있습니다. 어떤 면에서는 매우 나쁜 캐시처럼 작동합니다(따라서 이름).

이 패턴이 현재 상태에서 Redux와 잘 작동하는지 확인하기 위해 고군분투하고 있습니다. 내가 아닌 프로그래머가 작성했을 때와 서스펜스가 데이터 가져오기를 위해 '준비'되었을 때 이것이 어떻게 보일지에 대한 발견이 있었습니까? 현재로서는 명령적 플래그 가져오기와 함께 Redux를 단독으로 사용하는 것보다 훨씬 더 힘든 작업입니다.

Redux에 자체 후크 가 있으면 이 두 가지를 함께 사용하는 데 있어 가장 큰 어려움은 Redux가 노출되지 않아야 하는 컨텍스트와 함께 HOC를 사용한다는 점이므로 이 작업은 훨씬 간단해질 것입니다. 대답은 :)

Suspense는 외부 캐시와 함께 작동하기 위한 것입니다(상태에 의해 구동되는 Hook이 아님 ). 간단한 사용 사례에서 작동하는 그러한 캐시의 참조 구현을 제공할 것입니다. 릴레이는 자체 캐싱 메커니즘을 구현합니다. 다른 모든 도구(예: Apollo)도 호환 가능한 자체 캐시를 구현할 수 있으며, 이 두 가지 구현에서 영감을 얻을 수 있습니다.

돌연변이/무효화는 답변이 필요한 유일한 질문이 아닙니다. 우리는 또한 다음 사항에 대해 생각할 필요가 있습니다. 스피너를 표시 할 시기 , 매달린 트리 외부에 있을 수 있는 "인라인 표시기"와 같은 일반적인 패턴, 조정 로드 상태(하향식 순서로 잠금 해제해야 하거나 원래 상태로 들어 오는 것의 경우) 준비됨), 목록의 스트리밍 렌더링, 이것이 부분 수화에 미치는 영향 등. 우리는 이러한 작업을 하고 있지만 아직 "공식 권장 사항"은 없습니다. 있을 때 업데이트를 발표하는 블로그에서 알 수 있습니다.

참고로 데이터 가져오기를 위한 Suspense는 사람들이 익숙했던 것과는 충분히 다른 멘탈 모델입니다. Redux와 같은 매우 제한되지 않은 메커니즘과 통합될 때 반드시 강력할 것이라고 기대하는 것은 공정하지 않다고 생각합니다. 그러나 우리는 보게 될 것입니다. 지금은 뭐라 말씀드리기 어렵습니다.

@gaearon "우리가 이런 일을 하고 있다"고 말할 때 내가 구독할 수 있는 문제가 있거나 이러한 토론이 비공개로 진행되나요?

@gaearon님 감사합니다 :)

@ntucker 언제나처럼 진행 중인 활동을 PR로 볼 수 있습니다. 예: https://github.com/facebook/react/pull/14717 , https://github.com/facebook/react/pull/14884 , https://github.com/facebook/react/pull/15061 , https://github.com/facebook/react/pull/15151 , https://github.com/facebook/react/pull/15272 , https://github.com/facebook/react/pull/15358 , https //github.com/facebook/react/pull/15367 등. 우리는 각 PR에 몇 가지 설명적인 정보를 넣으려고 노력하며 테스트에서 동작 변경 사항을 볼 수 있습니다. 실험에 대한 문서 막대는 여러 가지 이유로 낮습니다.

선택한 모델이 실제로 작동한다는 확신이 든 후에 더 자세한 설명을 게시하겠습니다. 모든 실험을 발생하는 대로 자세히 설명한다면 우리나 커뮤니티 모두에게 생산적이지 않을 것이라고 생각합니다. 첫 번째 실험의 대부분은 실패했으며, 각각의 실험을 문서화하고 설명하면 작업 속도가 느려집니다.

이것은 사람들이 나중에 우리가 원래 설계된 방식으로 작동하지 않는다는 것을 깨닫는 것을 중심으로 멘탈 모델을 구축하는 결과를 낳는 경우가 훨씬 더 많습니다. (방금 삭제한 maxDuration 하는 것과 같습니다.) 따라서 귀하의 시간과 시간을 모두 사용할 수 있을 때까지 반쯤 구운 아이디어를 공유하는 것을 보류하고 싶습니다. 이는 우리가 과거에 React를 개발한 방식과도 일치합니다. 무언가가 진정으로 준비되면(심지어 멘탈 모델의 이론적인 작성을 위해서라도), 우리는 그것을 문서화하고 설명하는 데 모든 주의를 집중할 것입니다.

참고로 데이터 가져오기를 위한 Suspense는 사람들이 익숙했던 것과는 충분히 다른 멘탈 모델입니다. Redux와 같은 매우 제한되지 않은 메커니즘과 통합될 때 반드시 강력할 것이라고 기대하는 것은 공정하지 않다고 생각합니다. 그러나 우리는 보게 될 것입니다. 지금은 뭐라 말씀드리기 어렵습니다.

@gaearon 다행스럽게도 Suspense의 멘탈 모델은 저와 완벽하게 일치합니다. 퍼즐 조각이 제자리에 놓이게 되어 매우 기쁩니다. 모든 노력에 감사드립니다!

지난 11월에 발표된 로드맵(https://reactjs.org/blog/2018/11/27/react-16-roadmap.html)에 따르면 Suspense의 "동시" 버전은 2019년 2분기로 예정되어 있습니다. Q3 2019. Q3가 아닌 Q3 또는 Q3 등의 측면에서 얻을 수 있는 업데이트가 있습니까?

이것은 내가 찾을 수 있는 최신 로드맵 업데이트였습니다. https://reactjs.org/blog/2019/08/08/react-v16.9.0.html#an -update-to-the-roadmap

우리는 10월에 실험적인 릴리스를 제공했습니다: https://reactjs.org/docs/concurrent-mode-intro.html. 이것은 우리가 프로덕션에서 실행 중인 것과 동일한 빌드입니다. API를 조정하고 더 높은 수준의 API를 구축하는 측면에서 아직 해야 할 일이 더 있지만 원하는 경우 시작할 수 있습니다.

서스펜스가 날 죽이고 있어

@gaearon 프로덕션에서 사용

우리는 모두 이 코드를 기반으로 사업을 하고 있으며 우리 모두가 여러분처럼 늪에 빠져 있다고 확신합니다. 약간의 명확성, 블로그, SOMETHING이 정말 도움이 될 것입니다. 거의 "Facebook에서 프로덕션 중이므로 완료되었습니다."와 같은 느낌이 듭니다.

@mschipperheyn

이것은 다년간의 프로젝트입니다. 정직한 대답은 우리가 2년 전에 시작했을 때 생각했던 것보다 훨씬 더 많은 작업을 낳았다는 것입니다.

그러나 좋은 소식은 이제 프로덕션에서 많이 사용 하기 때문에 누락된 부분이 명확하고 터널의 끝이 보입니다. 이론적인 것이 아닙니다. 광범위하게 채택할 준비가 되었다고 편안하게 말할 수 있기 전에 완료해야 하는 유한한 세트가 있습니다.

오늘날 다양한 작업 흐름의 대략적인 상태는 다음과 같습니다.

• <Suspense> 사용하여 코드 분할에 대한 API lazy . (16.6 반응에 제공)
  
  
  
  • 아시다시피 이미 이것을 사용할 수 있습니다.
  
  
• 동시 모드 API, 예: createRoot 및 useTransition . (에서 사용할 수있는 experimental 출시)
  
  
  
  • Flux와 유사한 라이브러리를 위한 호환성 솔루션입니다. ( 진행 중 @bvaughn , https://github.com/reactjs/rfcs/pull/147)
  
  
  • 우선순위 모델을 보다 합리적인 모델로 변경합니다. ( 진행 중 @acdlite , https://github.com/facebook/react/pull/18612 )
  
  
  • 마지막으로 보류 중인 전환만 완료되도록 허용합니다. ( 진행 중 @acdlite)
  
  
  • 오프스크린 API(@lunaruan 진행 중)
  
  
  • 서스펜스 콘텐츠 숨기기/표시 시 화재 효과
  
  
  • 오프스크린에 대한 콘텐츠 숨기기/표시 시 화재 효과
  
  
  • 필요할 때 Portal 자식 표시 및 숨기기
  
  
  • 스케줄링을 위한 진행 중인 표준화 작업에 맞춰 조정( 시작되지 않음 )
  
  
  • 알려진 주요 버그 수정( @gaearon 및 @acdlite 진행 중 )
  
  
  • 이벤트 의미를 변경합니다. ( 진행 중 @sebmarkbage @trueadm)
  
  
  • 보다 점진적인 채택을 가능하게 하기 위해 문서 대신 루트에 위임( 진행 중 , @trueadm)
  
  
  • 캡처 단계에서 개별 이벤트를 플러시합니다.
  
  
  • 명령형 코드를 더 잘 사용하려면 event 에서 기본 우선 순위를 가져오는 것이 좋습니다.
  
  
  • 다른 API 의미 및 기본값을 마무리합니다. ( 시작되지 않음 )
  
  
  • 타이핑과 문서를 업데이트하십시오.
  
  
• 데이터 가져오기에 대한 중단
  
  
  
  • 구성 요소 신호에 대한 저수준 지원은 렌더링할 준비가 되지 않았습니다(기술적으로 안정적인 React에서도 사용 가능 하지만 이 API는 안정적인 것으로 간주되지 않습니다).
  
  
  • 서버 렌더러는 Suspense 폴백을 즉시 플러시합니다(실험 릴리스에서 사용 가능 ).
  
  
  • GraphQL 사용 사례에 대한 솔루션 (릴레이 후크, 제공).
  
  
  • 비 GraphQL 사용 사례를 위한 솔루션( Next.js 와 공동으로 @sebmarkbage 진행 중 ).
  
  
  • 데이터 기반 종속성을 위한 번들러 통합. ( 진행 중 )
  
  
  • 컨텍스트를 포함한 Finalize Blocks API.
  
  
  • 일반 캐싱 솔루션. ( 시작되지 않음 )
  
  
  • 일종의 라우터 통합.
  
  

거의 "Facebook에서 프로덕션 중이므로 완료되었습니다."와 같은 느낌이 듭니다.

나는 그것이 어떻게 보일 수 있는지 알 수 있습니다. :-) 우리는 지난 몇 달 동안 이 문제에 대해 논스톱으로 작업해 왔으며 많은 기술적인 측면이 완료되었거나 거의 마무리 단계에 있습니다. 나머지 작업의 대부분은 두 가지 범주로 나뉩니다.

• 안정적인 릴리스에서 이를 강화하기 전에 초기 설계에서 발견한 결함을 수정합니다. 만약 우리가 지금 가지고 있는 것을 출시한다면, 우리는 몇 달 안에 중대한 주요 변경 사항을 따라야 할 것입니다. 혼란스러울 뿐입니다.

• 생태계 호환성 및 좋은 기본값. 오늘날 아무도 사용할 수 없는 것을 릴리스하는 것은 그들의 라이브러리나 기존 접근 방식에서 작동하지 않기 때문에 도움이 되지 않습니다. 따라서 대부분의 작업(예: useMutableSource 통한 Flux 계열 라이브러리와의 호환성, 더 나은 이벤트 의미 선택, 권장 캐싱 전략 제공)은 우리가 릴리스한 것을 실제로 사용할 수 있도록 하는 것입니다. 이것은 긴 꼬리입니다.

"오늘 사용할 수 있습니까?"라는 측면에서... 엄밀히 말하면 오늘 이 모든 것을 사용할 수 있습니다. 우리는하다. 특히 Relay Hooks와 Concurrent 모드를 사용합니다. 아직 중요한 변경 사항과 알려진 문제가 있으므로 현재 상태는 광범위하게 채택할 준비가 되었다고 생각하는 기준을 충족하지 못하고 있습니다. 물론, 버그나 API가 변경되는 것을 꺼려하지 않는다면 우리처럼 @experimental 릴리스를 사용할 수 있습니다.

저는 Facebook이 "완료"라는 측면에서 특별한 위치에 있다고 말하지 않습니다. 정반대로 우리는 아직 끝나지 않았습니다. 그러나 내부적으로는 우리가 구축하고 있는 것이 견고하다는 것을 알기 때문에 움직이는 기차의 상단에 변동과 구축을 기꺼이 감수할 용의가 있습니다. 이 무거운 dogfood가 없었다면 우리가 6개월 만에 발견한 결함을 발견하고 재설계하는 데 몇 년이 걸렸을 것입니다.

요약하자면, 해야 할 일이 더 있습니다.

@gaearon 업데이트 감사합니다! 그리고 제 목소리가 틀렸다면 사과드립니다. 나는 내가 몇 달 동안 트위터를 뒤지고 아무것도 찾지 못한 것에 약간 실망했다는 것을 인정합니다. 이 측면 Server renderer immediately flushes Suspense fallbacks (available in experimental releases) 은 구현을 위해 Apollo Graphql로 테스트할 때 시간을 할당할 수 있는 것처럼 보입니다.

예, 도서관 저자와 호기심 많은 사람들이 가지고 놀 준비가 되어 있어야 합니다. 누락된 부분은 대부분 "행복한 길"을 제공하는 것에 관한 것이지만 대부분의 배관은 거기에 있어야 합니다.

서버 렌더러는 Suspense 폴백을 즉시 플러시합니다(실험 릴리스에서 사용 가능).

이것에 대해 어디에서 읽을 수 있습니까? Concurrent Mode API Reference(실험적)를 기대했지만 운이 없었습니다.

누군가 Next.js, Relay Hooks 및 Concurrent Mode(SSR 포함)를 함께 스티칭하는 데모가 있다면 굉장할 것입니다. 그렇지 않으면 충분한 문서를 찾을 수만 있다면 운을 시험해 볼 수도 있습니다.

@CrocoDillon

SSR에 대한 추가 문서는 없지만 대부분 새로운 기본 동작이기 때문입니다.

구성 요소가 서버에서 일시 중단될 때보다 실험적인 릴리스가 있는 경우 대신 가장 가까운 Suspense 폴백을 플러시합니다. 그런 다음 클라이언트에서 createRoot(node, { hydrate: true }).render(<App />) 합니다.

이것은 이미 모든 새로운 수화 기능을 활성화합니다. 예를 들어 서스펜스 경계는 서버에서 생성된 폴백 HTML에 "첨부"된 다음 클라이언트 렌더링을 시도합니다.

또한 전체 앱이 로드 되기 전에 수분 공급을 시작할 수 있습니다. <App> 가 충전되면 수분을 공급할 수 있습니다. 코드가 준비되지 않았을 때 아래 구성 요소가 일시 중단되는 한(게으른 것과 유사). 이 경우 React가 하는 일은 서버 HTML 콘텐츠를 유지 하면서 Suspense 경계를 "첨부"하는 것입니다. 하위 구성 요소가 로드되면 계속 수분 공급됩니다. 수화된 부분은 대화형 및 재생 이벤트가 됩니다.

다음 통합 시도/예에 대해 @devknoll 에게 요청할 수 있습니다. 그는 아마 일부가 있습니다.

react@experimental 및 react-dom@experimental 하고 next.config.js 다음을 추가하여 Next.js에서 동시 모드를 활성화할 수 있습니다.

// next.config.js
module.exports = {
  experimental: {
    reactMode: 'concurrent'
  }
}

다음은 이에 대한 Next.js 토론입니다. https://github.com/zeit/next.js/discussions/10645

서버 렌더링에서 중단을 기다릴 수 있습니까(예: 정적 사이트 생성과 같은 경우)? 콜백을 사용하는 것이 좋은 기본값이라는 데 동의합니다. 재정의 가능한지 궁금합니다.

또한 전체 앱이 로드되기 전에 수분 공급을 시작할 수 있습니다. 언제수분을 공급할 수 있습니다. 코드가 준비되지 않았을 때 아래 구성 요소가 일시 중단되는 한(게으른 것과 유사). 이 경우 React가 하는 일은 서버 HTML 콘텐츠를 유지하면서 Suspense 경계를 "첨부"하는 것입니다. 하위 구성 요소가 로드되면 계속 수분 공급됩니다. 수화된 부분은 대화형 및 재생 이벤트가 됩니다.

@gaearon 일반적으로 서버에서는 컴포넌트를 렌더링할 수 있지만 클라이언트에서는 React.lazy를 사용한다는 뜻인가요? 서버에서 전체 마크업을 반환할 수 있지만 클라이언트에서 구성 요소 코드의 구문 분석 및 렌더링이 지연됩니다. 서버에서 렌더링된 마크업이 여기서 서스펜스 폴백 역할을 합니까?

@robrichard 실제로 React.lazy 시도하지는 않았지만(FB에서 다른 래퍼를 사용하고 Next에도 자체 버전이 있음) 이것이 작동하는 방식입니다. 확인할 가치가 있습니다 :-) 특정 제한 사항이 있습니다. 예를 들어 props를 업데이트하고 위에 메모 구제금융이 없는 경우 또는 그 위의 컨텍스트를 업데이트하는 경우 무엇을 해야 할지 모르기 때문에 이를 제거하고 대체를 표시해야 합니다. 그것으로.

@gaearon 현재 상태 부분수분은? #14717이 병합되었다는 것을 알고 있지만 어떤 릴리스로 만들어졌는지 의심스럽습니다.

unstable_createRoot API를 사용하는 한 오랫동안 모든 @experimental 릴리스에서 사용되었습니다.

데모는 다음과 같습니다. https://codesandbox.io/s/floral-worker-xwbwv?file=/src/index.js

@gaearon "데이터 기반 종속성"이 무엇을 의미하는지 자세히

@gaearon "데이터 기반 종속성"이 무엇을 의미하는지 자세히

물론 이죠. 위의 목록이 간결한 것에 대해 사과해야 합니다. 매우 압축되어 있고 이들 중 많은 부분이 중요한 별도의 하위 프로젝트입니다(이 때문에 시간이 걸리는 이유입니다).

귀하의 특정 질문에 답하기 전에 한 걸음 물러나서 좀 더 넓은 맥락을 말씀드리겠습니다. 더 넓은 맥락은 정말 좋은 데이터 가져오기 솔루션을 구축하는 것이 정말 정말 어렵다는 것입니다. 구현의 의미에서뿐만 아니라 디자인의 의미에서도. 일반적으로 코로케이션(데이터 요구 사항을 데이터가 사용되는 위치에 가깝게 유지)과 효율성(데이터 로드를 얼마나 일찍 시작하고 네트워크 폭포수를 피할 수 있는지) 간에 절충안을 만들어야 합니다. 이것은 소규모에서는 눈에 띄지 않지만 구성 요소의 수가 증가함에 따라 뛰어난 성능과 쓰기 쉬운 코드 중에서 선택해야 합니다. 많은 경우에 불행히도 둘 다 얻지 못합니다. 이것이 일반적으로 데이터 가져오기가 뜨거운 주제인 이유입니다.

우리는 "공식" React에 들어가는 것에 대해 매우 높은 기준을 가지고 있습니다. "Reacty"가 되려면 일반 React 구성 요소와 마찬가지로 구성해야 합니다. 이것은 우리가 수천 개의 구성 요소로 확장될 것이라고 믿지 않는 솔루션을 선의로 추천할 수 없다는 것을 의미합니다. 또한 성능을 유지하기 위해 복잡한 최적화된 방식으로 코드를 작성하도록 하는 솔루션을 권장하지 않습니다. FB에서 우리는 Relay 팀으로부터 많은 교훈을 얻었습니다. 우리는 모든 사람이 GraphQL을 사용할 수 있거나 Relay를 사용하고 싶어하지 않는다는 것을 알고 있습니다. 그러나 우리는 일반 React용 데이터 가져오기 솔루션이 Relay에서 어렵게 얻은 교훈 을

저는 이것이 단지 큰 앱에 관한 것이 아니라는 점을 강조하고 싶습니다. 문제는 큰 앱에서 가장 두드러지지만 npm에서 많은 구성 요소를 가져오는 작은 앱도 이러한 비효율성의 하위 집합으로 어려움을 겪습니다. 예를 들어 너무 많은 클라이언트 측 코드를 전달하고 이를 워터폴에 로드하는 것입니다. 또는 너무 많이 미리 로드합니다. 또한 작은 앱은 작은 앱으로 영원히 남아 있지 않습니다. React 구성 요소 모델이 앱의 복잡성에 관계없이 동일한 방식으로 작동하는 것처럼 모든 크기의 앱에 대해 잘 작동하는 솔루션을 원합니다.

이제 귀하의 특정 질문을 해결합니다. 릴레이에는 "데이터 기반 종속성"이라는 기능이 있습니다. 그것에 대해 생각하는 한 가지 방법은 동적 import 의 진화입니다. 동적 import 이 항상 효율적인 것은 아닙니다. 조건이 참일 때만 일부 코드를 로드하려는 경우(예: "사용자가 로그인했는지" 또는 "사용자에게 읽지 않은 메시지가 있습니까?"), 유일한 옵션은 느리게 트리거하는 것입니다. 그러나 이것은 무언가가 사용될 때만 가져오기(예: React.lazy )를 "시작"한다는 의미입니다. 사실 너무 늦었어요. 예를 들어, 여러 수준의 코드 분할 구성 요소(또는 데이터를 기다리는 구성 요소)가 있는 경우 가장 안쪽에 있는 구성 요소는 위에 있는 구성 요소가 로드된 후에만 로드를 시작합니다. 이것은 비효율적이며 네트워크 "폭포"입니다. 릴레이 "데이터 기반 종속성"을 사용하면 쿼리의 일부로 가져오려는 모듈을 지정할 수 있습니다. 즉, "일부 조건이 참이면 데이터 응답과 함께 이 코드 청크를 포함합니다". 이렇게 하면 필요한 모든 코드 분할 청크를 최대한 빨리 로드할 수 있습니다. 성능을 위해 코로케이션을 교환할 필요가 없습니다. 별 것 아닌 것처럼 보일 수 있지만 제품 코드에서 문자 그대로 초를 줄였습니다.

이제 다시, 우리는 Relay를 React에 넣지 않을 것이며 사람들이 GraphQL을 사용하도록 강요하고 싶지 않습니다. 그러나 개념적으로 기능 자체는 일반적이며 이에 대한 좋은 오픈 소스 솔루션을 사용하면 사람들이 오늘날보다 훨씬 더 많은 코드 분할을 수행할 수 있습니다(따라서 클라이언트 JS 코드를 훨씬 적게 제공합니다!). 해당 일반 기능은 호출되지 않습니다. "데이터 기반 종속성" — 제가 언급한 릴레이 이름일 뿐입니다. 이 기능은 GraphQL이 필요하지 않은 더 큰 권장 솔루션의 일부가 될 것입니다. 하나의 글머리 기호 목록 항목에 대해 설명할 내용이 많기 때문에 목록에서 해당 이름으로 참조했습니다.

이것이 해결되기를 바랍니다.