u/Neat_Living_6765

Hi everyone, I'm learning React Virtuoso and came across the term "DOM element recycling." I understand the basic idea of DOM elements, but how can they be "recycled"? Could someone explain it in simple terms? 🤔

const stop = useIntersectionObserver(
    ref,
    ([entry]) => {
      if (entry.isIntersecting) {
        setLoaded(true);
        stop(); // one-shot: stop observing once we've committed to loading
      }
    },
    { rootMargin: '200px' }, // start loading 200px before it scrolls in
  );

In the snippet, I noticed that useIntersectionObserver returns a function, which is assigned to the variable stop, and that returned function is then called inside the callback passed to useIntersectionObserver.

Actually, I'm not asking about useIntersectionObserver itself. I just want to ask about the pattern:

Function A returns Function B, and then Function B is called inside Function A's callback.

I've never written a function with that kind of structure before.

How often do you write functions like this?

Hi everyone,
I'm learning about throttle, and I've been confused about the difference between trailing and leading.
Could you review whether the logic below is correct or incorrect?

I’d really appreciate any help — I’ve been stuck for a few hours.

Delay= 1000ms

Leading= false, Trailing = true

0ms A → start window
200ms B → latest = B
400ms C → latest = C
700ms D → latest = D
1000ms → execute D ← trailing

1200ms E → start new window
1300ms F → latest = F
2200ms → execute F ← trailing

Leading=true, Trailing = false

0ms A → execute A immediately ← leading

200ms B → ignore
400ms C → ignore
700ms D → ignore

1000ms → throttle window ends

1200ms E → execute E immediately ← leading

1300ms F → ignore

Leading=true, Trailing = true

0ms A → execute A immediately ← leading
200ms B → latest = B
400ms C → latest = C
700ms D → latest = D
1000ms → execute D ← trailing
1200ms E → execute E immediately ← leading

1300ms F → latest = F
2000ms → execute F ← trailing

From my understanding, Fiber is React’s internal reconciliation engine, while the Virtual DOM is a conceptual UI representation (the “blueprint”). But I have one more question: is the Fiber tree the Virtual DOM? If so, to simplify further, is it just an object?

Hi Everyone!! From what I understand, I’m trying to explain Server Components in a simple way. Could you guys take a look and let me know if my understanding is correct and if my explanation is easy to understand?

Server Components

Normally, when a browser requests a React application, a JavaScript bundle is sent to the browser, whether it uses SSR or CSR.

• For SSR, that JavaScript bundle is used to hydrate the initial HTML rendered on the server, making the application interactive.
• For CSR, that JavaScript bundle is used to render the application's content into the HTML shell.

React Server Components are not included in that JavaScript bundle.

Server Components are rendered outside the browser, either at build time or at request time on the server. Their rendered result is represented in the RSC Payload.

The RSC Payload contains:

1. The rendered results of Server Components. (For conceptual understanding, we can think of this as a React tree or object)
2. References (Placeholder) to Client Components used inside those Server Components.
3. Props passed from Server Components to Client Components.

The main benefit of RSC is reducing the amount of JavaScript sent to the browser.

Server Components are especially useful for content that doesn't need browser interactivity.

From what I understand, I’m trying to explain Server Components in a simple way. Could you guys take a look and let me know if my understanding is correct and if my explanation is easy to understand?

Server Components

Normally, when a browser requests a React application, a JavaScript bundle is sent to the browser, whether it uses SSR or CSR.

• For SSR, that JavaScript bundle is used to hydrate the initial HTML rendered on the server, making the application interactive.
• For CSR, that JavaScript bundle is used to render the application's content into the HTML shell.

React Server Components are not included in that JavaScript bundle.

Server Components are rendered outside the browser, either at build time or at request time on the server. Their rendered result is represented in the RSC Payload.

The RSC Payload contains:

1. The rendered results of Server Components. (For conceptual understanding, we can think of this as a React tree or object)
2. References (Placeholder) to Client Components used inside those Server Components.
3. Props passed from Server Components to Client Components.

The main benefit of RSC is reducing the amount of JavaScript sent to the browser.

Server Components are especially useful for content that doesn't need browser interactivity.

Today, I'm reading about SSR and Streaming SSR.

At first, I got really confused about the relationship between Streams and Suspense.

I kept asking myself:

1. Do we have to use Suspense with Streaming SSR? What if using renderToPipeableStream() without wrapping any component with Suspense?
2. If Streaming SSR allows the server to send parts of the HTML to the browser as they are generated, why do we need Suspense?

For example, based on the definition of Streams in the articles (in the comment below), if I have a component that performs async task or lazy loading, Streams can send already-rendered components such as the Header and Footer first?? I mean, it still didn't make sense to me why we need Suspense (Sorry, I'm not a native English speaker, but I hope you can understand what I'm trying to say)

After searching more, this is my current understanding:

Streaming is a technique that keeps the HTTP response open, allowing React to progressively send chunks of the generated HTML to the client. It helps reduce the latency of transferring a large HTML response over the network.

However, when there is a component that needs to call backend APIs or perform another async task, I think React goes through two steps:

First, React waits for the full HTML to be generated, including the async tasks.

Then, React sends the HTML chunks to the client through streaming.

This is where Suspense comes in. Waiting for the full HTML to be completed takes time, so if we wrap the async component with Suspense, React can render and generate HTML for the other components outside the Suspense boundary first. In other words, Suspense takes this a step further and reduces the user's waiting time more because React doesn't have to wait for the entire HTML to be ready before starting to send it.

I'm still not sure if I understand this correctly, so I'd really appreciate any comments or corrections if I misunderstood something.