From eeca447746413e4a45b275a7fe5ea8ed4dd897dd Mon Sep 17 00:00:00 2001
From: jayming66 <mjw8941@gmail.com>
Date: Wed, 26 Jun 2024 13:33:07 +0900
Subject: [PATCH 1/3] =?UTF-8?q?How-React-19-(Almost)-Made-the-Internet-Slo?=
 =?UTF-8?q?wer=20=EB=B2=88=EC=97=AD?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...ct-19-(Almost)-Made-the-Internet-Slower.md | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 June/article/How-React-19-(Almost)-Made-the-Internet-Slower.md

diff --git a/June/article/How-React-19-(Almost)-Made-the-Internet-Slower.md b/June/article/How-React-19-(Almost)-Made-the-Internet-Slower.md
new file mode 100644
index 0000000..120ec46
--- /dev/null
+++ b/June/article/How-React-19-(Almost)-Made-the-Internet-Slower.md
@@ -0,0 +1,186 @@
+# [How React 19 (Almost) Made the Internet Slower](https://blog.codeminer42.com/how-react-19-almost-made-the-internet-slower/?utm_source=newsletter.reactdigest.net&utm_medium=referral&utm_campaign=react-19-and-suspense)
+
+### 🗓️ 번역 날짜: 2024.06.26
+
+### 🧚 번역한 크루: 마스터위(명재위)
+
+---
+
+Henrique Yuji  
+Updated On Jun 17, 2024  
+Keyword : **Frontend**, **React**
+
+리액트(React)는 여전히 [가장 인기 있고 널리 사용되는](https://gist.github.com/tkrotoff/b1caa4c3a185629299ec234d2314e190) 사용되는 UI 프레임워크로, 넷플릭스, 에어비앤비, 디스코드, 메타(페이스북, 인스타그램, 왓츠앱) 등 대형 웹사이트에서 사용됩니다. 수십억 명이 사용하는 사용자 인터페이스를 만드는 데 사용되므로, 인터넷 트래픽의 상당 부분이 React에 의해 처리된다고 볼 수 있습니다.
+
+올해 초 발표된 기대를 모았던 React 19는 많은 새로운 기능과 개발자 경험(DX) 개선을 포함하고 있지만, 최근까지 주목받지 못한 작은 변경 사항이 있었습니다. 이는 여러 React 기반 웹사이트의 성능을 크게 저하시킬 수 있는 잠재력을 가지고 있었습니다.
+
+모든 것은 다음 트윗에서 시작되었습니다:
+
+<img src="https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094424/tk-dodo-first-post.png?w=1200&ssl=1" width=400>
+
+[@TkDodo](https://x.com/TkDodo/status/1800501040766144676): "내가 상상하는 건가요, 아니면 React 18과 19에서 Suspense가 병렬 페칭을 처리하는 방식에 차이가 있나요? 18에서는 각 컴포넌트가 병렬로 분리되었지만, 19에서는 연속적으로 실행되는 것 같습니다."
+이는 두 개의 쿼리를 병렬로 실행하고, 둘 다 해결될 때까지 기다린 다음 전체 서브 트리를 보여줍니다.
+React 19에서는 내가 보기엔 쿼리들이 이제 폭포수처럼 실행됩니다. @rickhanlonii가 이런 얘기를 했던 것 같은데 지금은 evidence를 찾을 수 없습니다.
+
+---
+
+<img src="https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094427/adam-rackis-first-post-response.png?w=1200&ssl=1" width=400>
+
+[@AdamRackis](https://x.com/AdamRackis/status/1800588094560772224) : 이는 이해할 수 없는, 미친 변화입니다. 댓글에 따르면 클라이언트 컴포넌트에 적용되는 것 같습니다만, 병렬 페칭은 여전히 RSC에서 작동합니다.
+이는 react-query를 망치며, React로 데이터를 관리하는 유일한 좋은 방법입니다.
+냉정한 판단이 있기를 바라지만, 그러지 않을 것 같네요.
+
+---
+
+<img src="https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094454/tanner-response.png?w=1200&ssl=1" width=400>
+
+@TkDodo : 이제 확실히 React 19의 suspense와 형제 사전 렌더링 변경 사항에 대해 블로그에 써야겠어요. React 핵심 팀 외에는 이 거래가 옳다고 생각하는 사람을 아직 본 적이 없어요. v19.0.0은 아직 출시되지 않았으니, 그들을 재고하도록 할 수 있는 가능성이 있을지도 몰라요.
+
+---
+
+[@tannerlinsley](https://x.com/tannerlinsley/status/1800903098464096664) : "그래요, 이건 나쁜 결정처럼 느껴져요, 특히 기존 애플리케이션과 사용 사례를 자동으로 더 나쁘게 만들기 때문에."
+
+---
+
+<img src='https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094430/adam-rackis-vercel.png?w=1200&ssl=1' width=400>
+
+[@AdamRackis](https://x.com/AdamRackis/status/1800663066922963264) : 저는 간절히 바라건대 Vercel, 그리고 이제는 더욱 우려되는 *React 핵심 팀*이 모든 사람이 콘텐츠를 가능한 빨리 앞에 보여주어 지루한 사용자가 뒤로 가기 버튼을 누르지 않도록 하는 것이 최우선인 전자 상거래 사이트를 배포하는 것은 아니라는 점을 이해하기를 바랍니다.
+
+---
+
+<br>
+
+도미닉(TkDodo)을 모르는 분들을 위해 설명하자면, 그는 널리 사용되는 TanStack Query의 주요 유지 관리자 중 한 명이며, 전설적인 태너 린즐리(Tanner Linsley)와 함께 일하고 있습니다.
+
+하지만 다시 본론으로 돌아가서, 여기서 논의되는 변경 사항은 React 19에서 동일한 Suspense 경계 내 형제 요소의 병렬 렌더링을 비활성화한다는 것입니다. 이는 형제 요소 내부에서 가져오는 데이터에 대한 데이터 페칭 폭포수를 도입하게 됩니다.
+
+다음은 그 예시입니다:
+
+<img src='https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094440/real-case-waterfall-1.png?w=1200&ssl=1' width=400>
+
+<img src='https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094445/real-case-waterfall-2.png?w=1200&ssl=1' width=400>
+
+가장 큰 문제는 이 변화가 성능 측면에서 중요한 변경 사항이지만, 이 패턴에 의존하는 많은 사람들에게 영향을 미칠 것이라는 점입니다. 그럼에도 불구하고 이 변경 사항이 단 한 줄의 불명확한 글머리로 언급되었다는 점입니다.
+
+<img src='https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094436/react-19-migration.png?w=1200&ssl=1' width=400>
+
+제가 방금 말한 내용이 헷갈리셨다면, 당신만 그런 것이 아닙니다. 저도 처음 이 글을 접했을 때 그렇게 느꼈습니다. 걱정하지 마세요. 곧 모든 것이 이해될 것입니다.
+
+## Suspense 복습
+
+이 내용을 이해하려면 먼저 React의 Suspense에 대해 간략히 복습해야 합니다.
+
+Suspense는 자식 컴포넌트가 로딩을 마칠 때까지 대체 내용을 표시할 수 있게 하는 React 컴포넌트입니다. 자식 컴포넌트가 지연 로드되거나, Suspense를 사용한 데이터 페칭 메커니즘을 사용할 때 유용합니다.
+
+사용 예시는 다음과 같습니다:
+
+```jsx
+<Suspense fallback={<Loading />}>
+  <ComponentThatFetchesDataOrIsLazyLoaded />
+</Suspense>
+```
+
+Suspense는 오랫동안 React API의 일부였지만, 공식적으로 승인된 사용법은 React.lazy와 함께 지연 로딩을 사용하는 것이었습니다. 이는 앱을 코드 분할하고 필요한 경우에만 분할된 부분을 로드하는 데 매우 유용합니다.
+
+React.lazy를 사용하면 처음 지연 로드된 컴포넌트를 렌더링하려고 할 때 Suspense 경계를 트리거하고, 컴포넌트 코드를 가져올 때까지 대체 내용을 렌더링한 다음 컴포넌트 자체를 렌더링합니다.
+
+오랫동안 클라이언트 측에서 Suspense를 위한 공식 데이터 페칭 지원이 약속되었지만, 지금까지 실현되지 않았습니다. 그럼에도 불구하고 많은 라이브러리(예: TanStack Query)는 React 내부를 조사하여 이를 구현했습니다. 결과적으로 현재 많은 프로덕션 애플리케이션이 클라이언트 측 데이터 페칭에 Suspense를 사용하고 있습니다.
+
+## 변화 이해하기
+
+현재(React 18.3.1 기준) 동일한 Suspense 경계 내에서 여러 컴포넌트와 함께 Suspense 지원 데이터 페칭 또는 지연 로딩을 사용할 때, React는 첫 번째 형제 컴포넌트가 중단되더라도 모든 형제를 렌더링하려고 시도합니다.
+
+실제로 이는 이러한 형제 컴포넌트 내에서 발생하는 데이터 페칭 또는 지연 로딩이 모두 병렬로 시작된다는 것을 의미합니다.
+
+이 생각에 대한 예시를 보시죠 :
+
+```jsx
+function App() {
+  return (
+    <>
+      <Suspense fallback={"Loading..."}>
+        <ComponentThatFetchesData val={1} />
+        <ComponentThatFetchesData val={2} />
+        <ComponentThatFetchesData val={3} />
+      </Suspense>
+    </>
+  );
+}
+
+const ComponentThatFetchesData = ({ val }) => {
+  const result = fetchSomethingSuspense(val);
+
+  return <div>{result}</div>;
+};
+```
+
+Demo: https://stackblitz.com/edit/vitejs-vite-x3nv7r?file=src%2FApp.jsx
+
+이 예시에서는 (React 18에서) `fetchSomethingSuspense`가 첫 번째 `ComponentThatFetchesData`를 중단시켜도, React는 여전히 형제 컴포넌트를 렌더링하려고 시도하여 각각의 데이터 페칭이 병렬로 시작됩니다.
+
+이를 확인하기 위해 콘솔에서 각 데이터 페칭이 언제 트리거되는지 로그를 확인할 수 있습니다:
+
+<img src='https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094450/stack-blitz-1.png?w=1200&ssl=1' width=400>
+
+모든 데이터 페칭이 거의 동시에 시작됩니다.
+
+이제 동일한 코드를 React 19 (canary)에서 실행했을 때 어떤 일이 발생하는지 살펴보겠습니다:
+
+Demo: https://stackblitz.com/edit/vitejs-vite-55rddj?file=src%2FApp.jsx
+
+<img src='https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094453/stack-blitz-2.png?w=1200&ssl=1' width=400>
+
+콘솔을 다시 확인해 보면 이제는 폭포수 형태가 나타나며, 각 데이터 페칭이 이전 페칭이 완료된 후에야 시작되는 것을 알 수 있습니다.
+
+이것은 다음 PR에서 일어났습니다 :
+https://github.com/facebook/react/pull/26380
+
+이 PR에 의해 도입된 변경 사항 이후, React는 동일한 Suspense 경계 내의 모든 형제 요소를 렌더링하려고 시도하는 대신, 첫 번째로 중단되는 요소에서 멈추게 됩니다. 이러한 경우, 첫 번째 컴포넌트를 렌더링하려고 시도한 후 중단되면, 데이터 페칭이 완료된 후에야 다음 형제 요소로 넘어가고, 다시 중단됩니다.
+
+이 새로운 동작은 데이터 페칭을 위한 Suspense 사용뿐만 아니라, 오래된 패턴으로 더 널리 사용되는 React.lazy 사용에도 영향을 미칩니다.
+
+<img src='https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094434/lazy-loading.png?w=1200&ssl=1' width=400>
+
+[@bentonnnnnn](https://x.com/bentonnnnnn/status/1800940807618171270) : 예상대로 이 변경 사항은 지연 로드된 컴포넌트(react.lazy)에도 영향을 미칩니다.
+이제 더 이상 병렬로 가져오지 않기 때문에 로딩 시간은 두 페치의 합이 되며, 이는 큰 후퇴로 간주되어야 합니다.
+
+---
+
+## 근거와 DX 영향
+
+이 변경의 근거는, 실제로 중단되기 전에 모든 형제 요소를 렌더링하려고 시도하는 것은 비용이 들며, 본질적으로 fallback을 표시하는 것을 지연시킨다는 점입니다. 또한 이 변경은 React 팀이 React 18 이전에 Suspense를 도입하면서부터 추진해 온 "fetch as you render" 접근 방식과 일치합니다.
+
+이상적으로는, 컴포넌트 렌더링 시 데이터 페칭을 시작하는 대신, 가능한 빨리 데이터를 가져오는 것이 좋습니다.
+
+비록 성능 면에서는 최상의 접근 방식이지만, 이는 컴포넌트와 데이터 요구 사항을 함께 배치하는 것을 어렵게 만들어 개발자 경험(DX)에 큰 단점을 안겨줍니다.
+
+이 주제에 대해 이미 많은 논의가 있었고, 이 문제를 해결하기 위해 특별히 만들어진 라이브러리도 존재하기 때문에 여기서 깊이 다루지는 않겠습니다. 다만, 이 특정 문제에 대해 이야기하는 몇 가지 트윗을 남기겠습니다.
+
+<img src='https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094418/teemu-taskula-1.png?w=1200&ssl=1' width=400>
+
+[@teemu_taskula](https://x.com/teemu_taskula/status/1800770818097754509) : Dominik의 고통이 느껴지네요 😟 이건 React의 주요 설계 원칙인 composition에 반하는 것 아닌가요? 제가 제대로 이해한 게 맞다면, 이제 복잡한 사전 페칭 트릭 없이는 데이터 요구를 구성할 수 없게 되었습니다. 아니면 모든 데이터 페칭을 공통 부모로 올려야 하죠.
+데이터 페칭을 공통 부모로 올려야 한다면 Suspense를 사용하는 의미가 무엇인가요? 저는 비동기 작업 조정을 더 쉽게 만드는 것이 Suspense의 목적이라고 생각했습니다. 만약 view의 루트에서 데이터 페칭을 시작해야 한다면, 차라리 Suspense 없이 데이터를 쿼리하는 것이 낫습니다.
+
+---
+
+여기서 중요한 점은 컴포넌트와 그 데이터 요구 사항의 최적의 성능 특성과 공동 배치를 동시에 달성하는 것이 **컴파일러** 없이 불가능하다는 것입니다. 이는 Relay가 수행하는 작업입니다.
+
+## 결론
+
+다행히도 이 이야기는 해피엔딩으로 끝났습니다. 많은 공개 반발, 열띤 토론, 그리고 아마도 배후에서의 상당한 논의 끝에, React 팀은 이 변경 사항을 보류하기로 결정했습니다.
+
+<img src='https://i0.wp.com/d604h6pkko9r0.cloudfront.net/wp-content/uploads/2024/06/17094448/sophie.png?w=1200&ssl=1' width=400>
+
+[@sophiebits](https://x.com/sophiebits/status/1801663976973209620) : 좋은 소식입니다. Suspense와 관련된 문제에 대해
+@rickhanlonii, @en_JS, @acdlite와 만났습니다.
+
+우리는 단일 페이지 애플리케이션(SPA)에 대해 많은 관심을 가지고 있으며, 팀이 오늘날 많은 사람들이 이 기능에 의존하고 있다는 것을 잘못 판단했습니다.
+여전히 프리로딩을 권장하지만, 항상 실용적이지 않다는 것을 인식하고 있습니다.
+좋은 해결책을 찾을 때까지 React 19.0 릴리스를 보류할 계획입니다.
+추가 소식이 있을 예정입니다.
+
+---
+
+이것은 커뮤니티가 Meta와 Vercel 외부에서 React가 어떻게 사용되는지에 대한 고려 없이 도입된 변경 사항에 반발한 첫 번째 사례가 아닙니다. React 팀과 특히 Vercel이 RSCs를 React로 구축하는 기본 요소로 만들려는 추진이 그 한 사례입니다.
+
+React의 유지 관리자들이 React의 미래를 위해 최선이라고 생각하는 것과 커뮤니티의 의견 사이에 불일치가 명확히 존재합니다. 이러한 커뮤니케이션 문제들이 더 심화될지는 아직 지켜봐야 합니다.

From 2815810b370892d2a474ab22edf19f05695cf073 Mon Sep 17 00:00:00 2001
From: jayming66 <mjw8941@gmail.com>
Date: Mon, 8 Jul 2024 01:00:22 +0900
Subject: [PATCH 2/3] =?UTF-8?q?docs:=20wait=20for=20pening=20-=20=EC=84=9C?=
 =?UTF-8?q?=EC=8A=A4=ED=8E=9C=EC=8A=A4=20=EC=95=8C=EA=B3=A0=EB=A6=AC?=
 =?UTF-8?q?=EC=A6=98=20=ED=83=90=ED=97=98?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...nding:-A-Suspense-algorithm-exploration.md | 263 ++++++++++++++++++
 1 file changed, 263 insertions(+)
 create mode 100644 June/article/Wait-for-pending:-A-Suspense-algorithm-exploration.md

diff --git a/June/article/Wait-for-pending:-A-Suspense-algorithm-exploration.md b/June/article/Wait-for-pending:-A-Suspense-algorithm-exploration.md
new file mode 100644
index 0000000..fea6492
--- /dev/null
+++ b/June/article/Wait-for-pending:-A-Suspense-algorithm-exploration.md
@@ -0,0 +1,263 @@
+## 🔗 [Wait for pending: A Suspense algorithm exploration](https://dev.to/alexandereardon/wait-for-pending-a-not-great-alternative-suspense-algorithm-1gdl)
+
+### 🗓️ 번역 날짜: 2024.07.08
+
+### 🧚 번역한 크루: 마스터위(명재위)
+
+---
+
+Alex Reardon  
+Updated On Jun 25, 2024  
+Keyword : **React**, **Javascript**
+
+React 19의 `<Suspense>` 타이밍에 대한 [흥미로운 논의](https://github.com/facebook/react/issues/29898)가 진행 중입니다.
+
+이 글에서는 `<Suspense>` 경계 내의 모든 대기 중인 promise가 해결된 후에 다시 렌더링을 시도하는 알고리즘이 어떻게 생길지 탐구합니다.
+
+> 이는 처음에는 메모장에 적어본 아이디어에서 출발해 제안서로 발전했지만, 접근 방식에 문제가 있음을 발견했습니다. 그럼에도 불구하고 기록하고 공유하기로 했습니다. 이로 인해 더 나은 아이디어가 나올 수도 있습니다!
+
+### TLDR
+
+'Wait for pending'은 react@18과 react@19(alpha) `<Suspense>` 알고리즘의 흥미로운 변형입니다. 평면 비동기 트리(flat async tree)에서는 'wait for pending'이 빠른 렌더 함수 호출과 최소한의 재렌더링을 허용합니다. 중첩된 비동기 컴포넌트가 있는 트리에서는 자식 비동기 컴포넌트의 초기 렌더링이 react@18 알고리즘보다 느려질 수 있습니다.
+
+### Background
+
+**react@18의 `<Suspense>`**
+
+- 가능한 모든 컴포넌트를 `<Suspense>` 경계 내에서 렌더링합니다.
+- 어떤 promise가 resolve 될 때마다 리렌더링합니다.
+- 더 이상 promise를 던지는 컴포넌트가 없을 때까지 계속합니다.
+
+결과적으로 많은 재렌더링이 발생하지만, 'fetch in render' 호출의 병렬화를 가능하게 하고, 모든 컴포넌트가 최대한 빨리 렌더링되도록 합니다.
+
+**react@19 (alpha)의 `<Suspense>`**
+
+- 컴포넌트가 promise를 던질 때 tree 렌더링을 중지합니다.
+- promise가 resolve될 때까지 기다립니다.
+- tree를 리렌더링합니다.
+- 더 이상 promise를 던지는 컴포넌트가 없을 때까지 계속합니다.
+
+최소한의 fl렌더링이 발생하지만, 'fetch in render' 호출이 순차적으로 이루어집니다(폭포수 형태(waterfall)).
+
+### 'Wait for pending' 알고리즘
+
+`<Suspense>` 타이밍('Wait for pending')에 대한 아이디어:
+
+- 형제 컴포넌트를 항상 렌더링합니다.
+- 모든 현재 던져진 promise가 해결될 때까지 자식 컴포넌트를 리렌더링하지 않습니다.
+
+어떻게 되는지 봅시다!
+
+'Wait for pending'은 현재의 react@18 `<Suspense>`알고리즘과 비슷합니다. 단, 어떤 promise가 resolve 될 때마다 모든 자식을 렌더링하는 대신, 현재 던져진 모든 promise가 resolve될 때만 렌더링합니다.
+
+- 형제 간 'fetch in render'가 병렬 fetch를 트리거할 수 있습니다.
+- 여전히 pre-fetching에 좋은 story를 가지고 있습니다.
+- 리렌더링으로 인한 낭비를 줄입니다.
+- 비싼 컴포넌트 렌더링이 `throw`하는 형제들과 함께 발생해도 여전히 중복됩니다. 하지만 적어도 이러한 중복 렌더링이 줄어듭니다.
+- 👎 중첩된 'fetch in render' 호출을 느리게 할 수 있습니다 (아래 참조).
+
+대략의 알고리즘
+
+1. 자식들을 렌더한다.
+2. 던져진 promise가 없으면 완료 - 그렇지 않으면 3단계로 이동한다.
+3. 모든 promise resolve 될 때까지 기다린다.
+4. 1단계로 돌아간다.
+
+### Example 1: Only siblings
+
+```jsx
+<Suspense fallback={'loading'}>
+  <A />
+  <B />
+<Suspense>
+```
+
+해당 예시에서, `A`와 `B` 둘다 그들의 렌더에 데이터를 위한 `fetch`가 있다.
+
+**react@18**
+
+Render 1
+
+- `A` 렌더되지만, promise 던짐
+- `B` 렌더되지만, promise 던짐
+
+Render 2
+
+- `A`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `B`가 렌더링되지만, promise 던짐
+
+Render 3
+
+- `B`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `B`가 렌더링됨
+
+**react@19 alpha timing**
+
+Render 1
+
+- `A` 렌더되지만, promise 던짐
+
+Render 2
+
+- `A`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `B`가 렌더링되지만, promise 던짐
+
+Render 3
+
+- `B`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `B`가 렌더링됨
+
+😢 렌더링에서 데이터를 가져오면(promise를 던지면) 폭포수(waterfall)가 발생함
+😊 잠재적으로 비용이 많이 드는 컴포넌트의 과도한 리렌더링을 방지함
+
+**Wait for pending**
+
+Render 1
+
+- `A` 렌더되지만, promise 던짐
+- `B` 렌더되지만, promise 던짐
+- **`A`와 `B`가 resolve 되길 기다림**
+
+Render 2
+
+- `A`가 렌더링됨
+- `B`가 렌더링됨
+
+✅ 이 경우, 제안된 알고리즘은 훌륭한 결과를 가져옵니다!
+
+### Example 2: children과 함께일 때
+
+여기서 'wait for pending' 알고리즘이 부담을 느끼게 됩니다.
+
+이제 `A`가 `ChildX`와 `ChildY`를 자식으로 렌더링하는데, 이들 또한 'fetch in render'를 수행합니다.
+
+```jsx
+<Suspense fallback={'loading'}>
+  <A>
+    <ChildX />
+    <ChildY />
+  </A>
+  <B />
+<Suspense>
+
+```
+
+**react@18**
+
+Render 1
+
+- `A` 렌더되지만, promise 던짐
+- `B` 렌더되지만, promise 던짐
+
+Render 2
+
+- `A`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `ChildX`가 렌더링되지만, promise 던짐
+- `ChildY`가 렌더링되지만, promise 던짐
+- `B`가 렌더링되지만, promise 던짐
+
+Render 3
+
+- `ChildX`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `ChildX`가 렌더링됨
+- `ChildY`가 렌더링되지만, promise 던짐
+- `B`가 렌더링되지만, promise 던짐
+
+Render 4
+
+- `ChildY`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `ChildX`가 렌더링됨
+- `ChildY`가 렌더링됨
+- `B`가 렌더링되지만, promise 던짐
+
+Render 5
+
+- `B`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `ChildX`가 렌더링됨
+- `ChildY`가 렌더링됨
+- `B`가 렌더링됨
+
+✅ ChildX와 ChildY가 가능한 빨리 렌더링됩니다.
+😢 많은 중복 재렌더링이 발생합니다.
+
+**react@19 alpha timing**
+
+Render 1
+
+- `A` 렌더되지만, promise 던짐
+
+Render 2
+
+- `A`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `ChildX`가 렌더링되지만, `B`가 promise 던짐
+
+Render 3
+
+- `ChildX`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `ChildX`가 렌더링됨
+- `ChildY`가 렌더링되지만, `ChildY`가 promise 던짐
+
+Render 4
+
+- `ChildY`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `ChildX`가 렌더링됨
+- `ChildY`가 렌더링됨
+- `B`가 렌더링되지만, `B`가 promise 던짐
+
+Render 5
+
+- `B`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `ChildX`가 렌더링됨
+- `ChildY`가 렌더링됨
+- `B`가 렌더링됨
+
+**제안한 알고리즘**
+
+Render 1
+
+- `A` 렌더되지만, promise 던짐
+- `B` 렌더되지만, promise 던짐
+- **`A`와 `B`가 resolve 되길 기다림**
+
+Render 2
+
+- `A`와 `B`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `ChildX`가 렌더링되지만, promise 던짐
+- `ChildY`가 렌더링되지만, promise 던짐
+- `B`가 렌더링됨
+- **`ChildX`와 `ChildY`가 resolve 되길 기다림**
+
+Render 3
+
+- `ChildX`와 `ChildY`의 promise가 resolve됨
+- `A`가 렌더링됨
+- `ChildX`가 렌더링됨
+- `ChildY`가 렌더링됨
+- `B`가 렌더링됨
+
+✅ react@18 알고리즘보다 중복 렌더링이 훨씬 적습니다.
+👎 ChildX와 ChildY는 B가 해결되기 전까지 'fetch in render' 호출을 시작할 수 없습니다. 이들은 부모의 가장 느린 형제가 해결될 때까지 기다려야 했습니다.
+🤔 react@19 알고리즘보다 병렬 처리가 더 많이 되지만, react@18보다 모든 컴포넌트의 초기 렌더링 시작이 더 느립니다.
+
+### 마무리 생각
+
+'Wait for pending'은 흥미로운 접근 방식입니다.
+
+flat async trees에서는 'wait for pending'이 렌더 함수 호출을 빠르게 하고 리렌더링을 최소화합니다. 그러나 중첩된 비동기 컴포넌트가 있는 트리에서는 자식 비동기 컴포넌트가 초기 렌더링을 시작하기 전에 부모 형제 컴포넌트가 렌더링을 완료해야 합니다. 중첩된 컴포넌트가 네트워크 호출과 같은 비용이 많이 드는 작업을 수행하는 경우, 가능한 한 빨리 초기 렌더링을 트리거하는 것이 이상적입니다(react@18 알고리즘). 'Wait for pending'은 react@19 접근 방식과 유사하지만, 각 레벨이 병렬 처리될 수 있습니다.
+
+다른 `<Suspense>` 알고리즘이 어떻게 생길지 생각해보는 것은 흥미로웠습니다! 여기까지 읽어주셔서 감사합니다 😅.
+
+Cheers

From dd5e1cb3b9797ce63710e865905b1a29de9c2a4f Mon Sep 17 00:00:00 2001
From: jayming66 <mjw8941@gmail.com>
Date: Mon, 8 Jul 2024 01:04:26 +0900
Subject: [PATCH 3/3] =?UTF-8?q?7=EC=9B=94=20=EA=B8=80=EB=A1=9C=20=EC=9D=B4?=
 =?UTF-8?q?=EB=8F=99?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../Wait-for-pending:-A-Suspense-algorithm-exploration.md         | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename {June/article => July}/Wait-for-pending:-A-Suspense-algorithm-exploration.md (100%)

diff --git a/June/article/Wait-for-pending:-A-Suspense-algorithm-exploration.md b/July/Wait-for-pending:-A-Suspense-algorithm-exploration.md
similarity index 100%
rename from June/article/Wait-for-pending:-A-Suspense-algorithm-exploration.md
rename to July/Wait-for-pending:-A-Suspense-algorithm-exploration.md