Location>code7788 >text

React-based virtual scrolling scheme

Popularity：254 ℃/2025-03-11 10:30:54

React-based virtual scrolling scheme

When rendering a list, we usually render all list items toDOMIn the meantime, when the data volume is large, this operation will cause the page to respond slowly, because the browser needs to process a large number ofDOMelement. At this time, we usually need virtual scrolling to achieve performance optimization. When we have a large amount of data that needs to be displayed in the form of a list or a table in the user interface, this performance optimization method can greatly improve the user experience and application performance. In this article, the implementation of virtual scrolling is carried out in two scenarios: fixed height and non-fixed height.

describe

Implementing virtual scrolling is usually not a very complicated thing, but we need to consider a lot of details. Before I implemented it in detail, I thought about an interesting thing, why virtual scrolling can optimize performance. We do it in the browserDOMWhen operating, thisDOMDoes it really exist, or we arePCWhen implementing window management, does this window really exist? Then the answer is actually very clear, these views, windows,DOMAll are simulated through graphical simulation, although we can provide it through the system or browser.APIIt can implement various operations very simply, but in fact, some content is an image drawn by the system for us. In essence, it is still generated by external input devices to generate state and behavior simulations, such as collision detection, etc., which are just states that the system shows through a large number of calculations.

Then, I wanted to learn some time agoCanvasThe basic operation of the graphic editor engine, so I implemented a very basic graphics editor engine. Because in the browserCanvasOnly the most basic graphic operation is provided, not that convenientDOMOperations so that all interactive events need to be simulated by the mouse and keyboard events. One very important point is to determine whether the two graphics intersect, thereby determining whether the graphics need to be redrawed as needed to improve performance.

So let's imagine that the simplest way to judge is to traverse all the graphics to judge whether they intersect with the graphics that are about to be refreshed. This may involve relatively complex calculations, and if we can judge in advance that certain graphics are impossible to intersect, we can save a lot of unnecessary calculations. Then the layer outside the viewport is a similar situation. If we can determine that the figure is outside the viewport, we do not need to judge its intersectivity, and we do not need to render itself, so the same is true for virtual scrolling, if we can reduce it.DOMThe number of calculations can be reduced a lot, thereby improving the runtime performance of the entire page. Needless to say, the performance of the first screen is reduced.DOMThe number of drawings on the first screen will definitely get faster.

Of course, the above is just my thoughts on improving page interaction or runtime performance. In fact, there are many discussions on the performance of virtual scroll optimization in the community. Such as reductionDOMThe number can reduce the browser's need to render and maintainDOMThe number of elements, and thus the memory usage also decreases, which allows the browser to respond to user operations faster. And browserreflowand repaintrepaintOperations usually require a lot of calculations, and withDOMThe increase in elements becomes more frequent and complex, and the need to manage it through virtual scrolling is reduced.DOMThe number can also significantly improve rendering performance. this

External virtual scrolling also has faster first-screen rendering time, especially full rendering of super large lists can easily lead to too long first-screen rendering time, and can also reduceReactWhat is caused by maintaining component statusJsPerformance consumption, especially in the presence ofContextIn the case of this, performance degradation may occur without special attention.

It will be mentioned in the article4A virtual scrolling implementation method, with fixed heightsOnScrollAchievable and uncertain heightsIntersectionObserver+OnScrollImplementation, relatedDEMOAll are there/WindrunnerMax/webpack-simple-environment/tree/react-virtual-listmiddle.

Fixed height

In fact, there are many references to the virtual scrolling solution in the community, especially fixed-height virtual scrolling can actually be made into a very general solution. Then here weArcoDesignofListComponents are used as examples to study the general virtual scrolling implementation. existArcoIn the example given we can see that it is passedheightAt this time, if we delete this property, the virtual scrolling cannot be started normally.

Then actuallyArcoIt is to calculate the height of the entire container through the number of list elements and the height of each element. Here, it should be noted that the scrolling container should actually be an element outside the virtual scrolling container, and the area inside the viewport can be passedtransform: translateY(Npx)To do the actual offset. When we scroll, we need to calculate the nodes that the current viewport actually needs to render through the actual scroll distance of the scroll bar and the height of the scroll container, and the actual height of the element we configured, while other nodes are not actually rendered, thereby realizing virtual scrolling. Of course, actually aboutArcoThere are many configurations for virtual scrolling, so I won't fully expand it here.

<List
  {/* ... */}
  virtualListProps={{
    height: 560,
  }}
  {/* ... */}
/>

Then we can first imagine that when we have the height of each element and the number of elements, it is obvious that we can calculate the height of the container. When we have the height of the container, we can get the child elements of the scroll container, and at this time we can get the scroll container with the scroll bar.

// packages/fixed-height-scroll/src/
// ...
const totalHeight = useMemo(() => itemHeight * , [itemHeight, ]);
// ...
<div
  style={{ height: 500, border: "1px solid #aaa", overflow: "auto", overflowAnchor: "none" }}
  onScroll={}
  ref={setScroll}
>
  {scroll && (
    <div style={{ height: totalHeight, position: "relative", overflow: "hidden" }}>
      {/* ... */}
    </div>
  )}
</div>

So now that the scroll container is already available, we need to focus on the list elements we are about to display, because we have scroll bars and actually have scroll offsets, so our scroll bar position needs to be locked in our viewport position. We just need to usescrollTop / itemHeightJust round it, and here we use ittranslateYTo do overall offset, usetranslateIt can also trigger hardware acceleration. In addition to the overall offset of the list, we also need to calculate the number of elements in the current viewport. The calculation here is also very simple because our height is fixed, and we only need to be divided from the scroll container at this time. In fact, this part is completed when instantiating the component.

useEffect(() => {
  if (!scroll) return void 0;
  setLen(( / itemHeight));
}, [itemHeight, scroll]);

const onScroll = useThrottleFn(
  () => {
    const containerElement = ;
    if (!scroll || !containerElement) return void 0;
    const scrollTop = ;
    const newIndex = (scrollTop / itemHeight);
     = `translateY(${newIndex * itemHeight}px)`;
    setIndex(newIndex);
  },
  { wait: 17 }
);

Dynamic height

Virtual scrolling with fixed height is more suitable for general scenarios. In fact, the fixed height here does not necessarily mean that the height of the element is fixed, but refers to the height of the element that can be directly calculated rather than rendered before it can be obtained. For example, the width and height of the image can be saved during upload, and then calculated through the width and height of the image and the width of the container during rendering. However, in fact, we have many scenarios where we cannot fully achieve the fixed height of the elements. For example, in rich text editors in online document scenarios, especially the height of text blocks, the performance is different under different fonts, browser widths, etc.

We cannot reach its height before it is rendered, which leads to us being unable to calculate its placeholder height in advance like the picture. Therefore, for virtual scrolling of document block structure, we must solve the problem of unfixed block height. Therefore, we need to implement a dynamic height virtual scrolling scheduling strategy to deal with this problem.

IntersectionObserver placeholder

If we need to determine whether an element appears in the viewport, we usually listenonScrollEvents are used to determine the actual location of elements, and now most browsers provideIntersectionObserverNative object is used to asynchronously observe the intersection state of the target element with its ancestor element or top document viewport. This is very useful for determining whether the element appears in the viewport range. So, we can also use it toIntersectionObserverto implement virtual scrolling.

It should be noted thatIntersectionObserverThe application scenario of an object is to observe the intersection state of the target element and the viewport. Our core concept of virtual scrolling is to not render elements in non-viewport areas, so there is actually a deviation here. In virtual scrolling, the target element does not exist or is not rendered, so its state cannot be observed at this time. So for cooperationIntersectionObserverThe concept of we need to render the actual placeholder, e.g.10kWe need to render the nodes of a list first10kThis is actually a reasonable thing, unless we noticed the performance of the list at the beginning, but in fact, most of them optimize page performance in the later stage, especially in complex scenarios such as documents, so assuming there was originally1w1 piece of data, even if only rendered3nodes, then if we only render the placeholder, we can still use the original page30kOptimize each node to roughly10kThis is also very meaningful for performance improvement itself.

In addition,/?search=IntersectionObserverIt can be observed that the compatibility is still good, and it can be used if the browser does not support it.OnScrollOr consider usingpolyfill. Then, let's implement this part of the content. First of all, we need to generate data. What we need to note here is that the uncertain height we are talking about should actually be called dynamic height. The height of the element needs to be obtained after we actually render. Before rendering, we only occupy the estimated height, so that the scroll container can produce a scrolling effect.

// packages/dynamic-height-placeholder/src/
 const LIST = ({ length: 1000 }, (_, i) => {
   const height = (() * 30) + 60;
   return {
     id: i,
     content: (
       <div style={{ height }}>
         {i}-height:{height}
       </div>
     ),
   };
 });

Next we need to createIntersectionObserver, same because our rolling container may not necessarily bewindow, so we need to create it on the scroll containerIntersectionObserver, in addition, we usually make a layer of the viewport areabuffer, used to load elements outside the viewport in advance, so as to avoid blank areas when the user scrolls.bufferThe size of the current viewport is usually half the height of the current viewport.

useLayoutEffect(() => {
   if (!scroll) return void 0;
   // Viewport threshold Take half of the height of the scroll container
   const margin = / 2;
   const current = new IntersectionObserver(onIntersect, {
     root: scroll,
     rootMargin: `${margin}px 0px`,
   });
   setObserver(current);
   return () => {
     ();
   };
 }, [onIntersect, scroll]);

Next we need to manage the status of the placeholder node, because we have the actual placeholder at this time, so we no longer need to estimate the height of the entire container, and we only need to actually scroll to the relevant position to render the node. We set three states for the node,loadingThe state is the placeholder state. At this time, the node can only render an empty placeholder.loadingIdentification, at this time we do not know the actual height of this node;viewportThe state is the real rendering state of the node, which means that the node is in the logical viewport. At this time, we can record the real height of the node;placeholderThe state is the rendered placeholder state, which is equivalent to the node scrolling from within the viewport to outside the viewport. At this time, the height of the node has been recorded, and we can set the height of the node to the real height.

loading -> viewport <-> placeholder

type NodeState = {
  mode: "loading" | "placeholder" | "viewport";
  height: number;
};

public changeStatus = (mode: NodeState["mode"], height: number): void => {
  ({ mode, height: height ||  });
};

render() {
  return (
    <div ref={} data-state={}>
      { === "loading" && (
        <div style={{ height:  }}>loading...</div>
      )}
      { === "placeholder" && <div style={{ height:  }}></div>}
      { === "viewport" && }
    </div>
  );
}

Of course oursObserverThe observation also requires configuration, and it is important to note here thatIntersectionObserverThe callback function will only carrytargetNode information, we need to find our actual information through node informationNodeTo manage node status, so here we useWeakMapto establish an element-to-node relationship, so that we can handle it easily.

export const ELEMENT_TO_NODE = new WeakMap<Element, Node>();
componentDidMount(): void {
  const el = ;
  if (!el) return void 0;
  ELEMENT_TO_NODE.set(el, this);
  (el);
}

componentWillUnmount(): void {
  const el = ;
  if (!el) return void 0;
  ELEMENT_TO_NODE.delete(el);
  (el);
}

Finally, it is the actual scrolling schedule. When the node appears in the viewport, we need to use it according toELEMENT_TO_NODEGet the node information, and then set the state according to the current viewport information. If the current node is in the state where the viewport is entered, we will set the node status toviewport, if the status of the exit viewport is now in the second way, the current state needs to be judged twice, if it is not the initial oneloadingThe status can be directly used toplaceholderSet to the node state, the height of the node is the actual height.

const onIntersect = useMemoizedFn((entries: IntersectionObserverEntry[]) => {
   (entry => {
     const node = ELEMENT_TO_NODE.get();
     if (!node) {
       ("Node Not Found", );
       return void 0;
     }
     const rect = ;
     if ( || > 0) {
       // Enter the viewport
       ("viewport", );
     } else {
       // Leave the viewport
       if ( !== "loading") {
         ("placeholder", );
       }
     }
   });
 });

IntersectionObserver virtualization

We also mentioned earlierIntersectionObserverThe goal is to observe the intersection state of the target element and the viewport. Our core concept of virtual scrolling is to not render elements in non-viewport areas. So can it be passedIntersectionObserverIt is actually OK to achieve virtual scrolling, but it may be necessaryOnScrollTo assist the forced refresh of the secondary node. Here we try to implement virtual lists using marker nodes and additional rendering, but it should be noted that this is because it is not usedOnScrollTo force refresh the node, there may be blank when scrolling quickly.

In previous placeholder schemes, we have implementedIntersectionObserverThe basic operations will not be described here. Here, our core idea is to mark the first position of the virtual list node, and the head and tail of the node are additionally rendered, which is equivalent to the head and tail node being a node outside the viewport. When the state of the head and tail node changes, we can control the pointer range of its head and tail through a callback function to achieve virtual scrolling. So before this, we need to control the state of the head and tail pointers to avoid negative values ​​or cross-border situations.

// packages/dynamic-height-virtualization/src/
const setSafeStart = useMemoizedFn((next: number | ((index: number) => number)) => {
  if (typeof next === "function") {
    setStart(v => {
      const index = next(v);
      return ((0, index), );
    });
  } else {
    setStart(((0, next), ));
  }
});

const setSafeEnd = useMemoizedFn((next: number | ((index: number) => number)) => {
  if (typeof next === "function") {
    setEnd(v => {
      const index = next(v);
      return ((, index), 1);
    });
  } else {
    setEnd(((, next), 1));
  }
});

Immediately afterwards, we need two arrays to manage all nodes and the height values ​​of nodes respectively. Because our nodes may not exist at this time, their status and height need additional variables to manage, and we also need two placeholders to serve as placeholders for the head and tail nodes to achieve the effect of scrolling in the scroll container. The placeholder block also needs to be observed, and its height needs to be calculated based on the nodes of the height value. Of course, this part of the calculation is written in a rough manner and there is still a lot of room for optimization, such as maintaining an additional monotonically increasing queue to calculate the height.

const instances: Node[] = useMemo(() => [], []);
const record = useMemo(() => {
  return ({ length:  }, () => DEFAULT_HEIGHT);
}, [list]);

<div
  ref={startPlaceHolder}
  style={{ height: (0, start).reduce((a, b) => a + b, 0) }}
></div>
// ...
<div
  ref={endPlaceHolder}
  style={{ height: (end, ).reduce((a, b) => a + b, 0) }}
></div>

When rendering a node, we need to mark its state, hereNodeThe data of nodes will become more, and here it mainly requires labelingisFirstNode、isLastNodeTwo states, andinitHeightIt needs to be passed from outside. As mentioned before, the node may not exist. If it is loaded from the beginning, the height will be incorrect. It is a problem of poor scrolling, so we need to pass it when the node is rendered.initHeight, this height value is the actual height recorded by the node rendering or the unreleased placeholder height.

<Node
  scroll={scroll}
  instances={instances}
  key={}
  index={}
  id={}
  content={}
  observer={observer}
  isFirstNode={index === 0}
  initHeight={record[]}
  isLastNode={index ===  - 1}
></Node>

Another issue that needs attention is viewport locking. When the height of nodes outside the visible area changes, if the viewport locking is not performed, the viewport jump will occur. It should be noted here that we cannot use itsmoothThe scrolling animation expression. If an animation is used, it may cause other node height changes and viewport locking fails during the scrolling process. At this time, the viewport area will still jump. We must clearly specify the scrolling position. If animation is really needed, it also needs to be simulated by slowly increasing the clear values ​​instead of directly using it.scrollToofsmoothparameter.

componentDidUpdate(prevProps: Readonly<NodeProps>, prevState: Readonly<NodeState>): void {
  if ( === "loading" &&  === "viewport" && ) {
    const rect = ();
    const SCROLL_TOP = 0;
    if ( !==  &&  < SCROLL_TOP) {
      ( - );
    }
  }
}

private scrollDeltaY = (deltaY: number): void => {
  const scroll = ;
  if (scroll instanceof Window) {
    ({ top:  + deltaY });
  } else {
     =  + deltaY;
  }
};

Next is the key callback function processing, which involves relatively complex state management. First of all, there are two placeholder nodes. When the two placeholder nodes appear in the viewport, we believe that other nodes need to be loaded at this time. Taking the starting placeholder as an example, when it appears in the viewport, we need to move the starting pointer forward, and the number of forward shifts needs to be calculated based on the range of the actual viewport crossing.

const isIntersecting = || > 0;
 if ( === ) {
   // Start placeholder enters viewport
   if (isIntersecting && > 0) {
     const delta = || 1;
     let index = start - 1;
     let count = 0;
     let increment = 0;
     while (index >= 0 && count < delta) {
       count = count + record[index];
       increment++;
       index--;
     }
     setSafeStart(index => index - increment);
   }
   return void 0;
 }
 if ( === ) {
   // End placeholder to enter viewport
   if (isIntersecting && > 0) {
     // ....
     setSafeEnd(end => end + increment);
   }
   return void 0;
 }

Next, like the placeholder plan, we also need toELEMENT_TO_NODETo obtain node information, then our height record variable needs to be updated at this time. Since we areIntersectionObserverThe actual scrolling direction cannot be judged during the callback, and it is not easy to judge the actual scrolling range, so we need to use the previous mentionedisFirstNodeandisLastNodeInformation to control the head and tail cursor pointer.FirstNodeEntering the viewport is considered to be scrolling down, and at this time, the nodes in the upper range need to be rendered, andLastNodeEntering the viewport is considered to be scrolling upwards, and at this time, the nodes in the range below need to be rendered.FirstNodeThe viewport is considered to be scrolling upward, and at this time, the node in the upper range needs to be removed, andLastNodeThe disengagement viewport is considered to be scrolling down, and at this time, the nodes in the lower range need to be removed. Here we can notice that we use to increase the node rangeTHRESHOLD, while reducing the node range is1, here is the head and tail nodes we need to render additionally.

const node = ELEMENT_TO_NODE.get();
 const rect = ;
 record[] = ;
 if (isIntersecting) {
   // Enter the viewport
   if () {
     setSafeStart(index => index - THRESHOLD);
   }
   if () {
     setSafeEnd(end => end + THRESHOLD);
   }
   ("viewport", );
 } else {
   // Leave the viewport
   if () {
     setSafeStart(index => index + 1);
   }
   if () {
     setSafeEnd(end => end - 1);
   }
   if ( !== "loading") {
     ("placeholder", );
   }
 }

Finally, because this state is difficult to control and perfect, we also need to provide a guarantee for it to prevent too many nodes on the page. Of course, even if there are nodes left, there is no problem. It is equivalent to downgrading to the placeholder scheme we mentioned above. In fact, there will be no large number of nodes, which is equivalent to the lazy loading placeholder nodes implemented here. However, we still provide a processing solution here, and we can use the node status to identify whether the node is used as a dividing line and needs to be actually processed as the head and tail cursor boundary.

public prevNode = (): Node | null => {
  return [ - 1] || null;
};
public nextNode = (): Node | null => {
  return [ + 1] || null;
};
// ...
const prev = ();
const next = ();
const isActualFirstNode = prev?. !== "viewport" && next?. === "viewport";
const isActualLastNode = prev?. === "viewport" && next?. !== "viewport";
if (isActualFirstNode) {
  setSafeStart( - THRESHOLD);
}
if (isActualLastNode) {
  setSafeEnd( + THRESHOLD);
}

OnScroll scroll event listening

Then, we can't forget the commonly used virtual scrolling.OnScrollThe solution is actually relative to the useIntersectionObserverJust a virtual scrollOnScrollThe solution is simpler, and of course it is also more likely to have performance problems. useOnScrollThe core idea is to also require a scroll container, and then we need to listen to the scroll event. When the scroll event is triggered, we need to calculate the nodes in the current viewport based on the scroll position, and then calculate the nodes that actually need to be rendered according to the height of the node, thereby realizing virtual scrolling.

So what is the difference between the virtual scrolling at dynamic height and the virtual scrolling at fixed height we implemented at the beginning? First, it is the height of the scroll container. We cannot know how high the scroll container is at the beginning, but can only know the actual height during continuous rendering; secondly, we cannot directly calculate the node that needs to be rendered based on the scrolling height, and at the beginning of our previous renderingindexThe cursor is calculated directly based on the scroll container height and the total height of all nodes in the list. In the virtual scrolling of dynamic height, we cannot obtain the total height, and the same is true for the length of the rendering node. We cannot know how many nodes it needs to be rendered in this rendering; in addition, it is not easy for us to judge the height of the node from the top of the scroll container, which is what we mentioned earlier.translateY, We need to use this height to support the rolling area so that we can actually roll.

So the values ​​we are talking about cannot be calculated. Obviously, this is not the case. Without any optimization, these data can be computed by force. In fact, for modern browsers, the performance consumption required to perform addition calculations is not very high. For example, we implement1In fact, the time consumption is less than ten thousand times1ms。

("addition time");
let count = 0;
for (let i = 0; i < 10000; i++) {
  count = count + i;
}
(count);
("addition time"); // 0.64306640625 ms

Then we will roughly calculate the data we need in a traversal way, and at the end we will talk about the basic optimization plan. First of all, we still need to record the height, because the node does not necessarily exist in the view, so at the beginning we store it at the basic placeholder height. After the node is actually rendered, we update the node height.

// packages/dynamic-height-scroll/src/
const heightTable = useMemo(() => {
  return ({ length:  }, () => DEFAULT_HEIGHT);
}, [list]);

componentDidMount(): void {
  const el = ;
  if (!el) return void 0;
  const rect = ();
  [] = ;
}

Remember what we talked about beforebufferWell, inIntersectionObserverProvided inrootMarginConfigure the viewportbuffer, and inOnScrollWe need to maintain it ourselves, so we need to set up abufferVariable, when the scroll container is actually created, we will update thisbuffervalue and scroll container.

const [scroll, setScroll] = useState<HTMLDivElement | null>(null);
const buffer = useRef(0);

const onUpdateInformation = (el: HTMLDivElement) => {
  if (!el) return void 0;
   =  / 2;
  setScroll(el);
  ().then();
};

return (
<div
  style={{ height: 500, border: "1px solid #aaa", overflow: "auto", overflowAnchor: "none" }}
  ref={onUpdateInformation}
>
  {/* ... */}
</div>
);

Next we will deal with two placeholder blocks, which are not used heretranslateYTo do the overall offset, instead directly use the placeholder block to support the rolling area. At this time, we need to calculate the specific placeholder based on the head and tail cursor. In fact, this is the time consumption problem of the calculation of ten thousand times of addition we mentioned before. Here we directly traverse the calculation height.

const startPlaceHolderHeight = useMemo(() => {
  return (0, start).reduce((a, b) => a + b, 0);
}, [heightTable, start]);

const endPlaceHolderHeight = useMemo(() => {
  return (end, ).reduce((a, b) => a + b, 0);
}, [end, heightTable]);

return (
  <div
    style={{ height: 500, border: "1px solid #aaa", overflow: "auto", overflowAnchor: "none" }}
    onScroll={}
    ref={onUpdateInformation}
  >
    <div data-index={`0-${start}`} style={{ height: startPlaceHolderHeight }}></div>
    {/* ... */}
    <div data-index={`${end}-${}`} style={{ height: endPlaceHolderHeight }}></div>
  </div>
);

Then we need toOnScrollThe processing of the node content we need to render in the event is actually mainly to process the cursor position of the head and tail. For the first cursor, we can directly calculate the cursor based on the scroll height. When the height of the first node is greater than the scroll height, we can think that the cursor at this time is the first node we need to render, and for the tail cursor we need to calculate based on the height of the head cursor and the scroll container. When we also traverse to the node that exceeds the height of the scroll container, we can think that the cursor at this time is the tail node we need to render. Of course, don't forget ours in this cursor calculationbufferData, this is the key to avoid blank areas when scrolling.

const getStartIndex = (top: number) => {
  const topStart = top - ;
  let count = 0;
  let index = 0;
  while (count < topStart) {
    count = count + heightTable[index];
    index++;
  }
  return index;
};

const getEndIndex = (clientHeight: number, startIndex: number) => {
  const topEnd = clientHeight + ;
  let count = 0;
  let index = startIndex;
  while (count < topEnd) {
    count = count + heightTable[index];
    index++;
  }
  return index;
};

const onScroll = useThrottleFn(
  () => {
    if (!scroll) return void 0;
    const scrollTop = ;
    const clientHeight = ;
    const startIndex = getStartIndex(scrollTop);
    const endIndex = getEndIndex(clientHeight, startIndex);
    setStart(startIndex);
    setEnd(endIndex);
  },
  { wait: 17 }
);

Because I want to talk about the most basic principle of virtual scrolling, there is basically no optimization in the example here. It is obvious that our high traversal processing is relatively inefficient. Even if the consumption of 10,000 addition calculations is not large, in large applications, we should try to avoid doing such a large number of calculations. Then an obvious optimization direction is that we can implement height cache. Simply put, we can cache the calculated height, so that the cache height can be directly used in the next calculation, without traversing the calculation again. When there is a height change and needs to be updated, we can recalculate the cache height from the current node to the latest cache node. Moreover, this method is equivalent to an incremental ordered array, and the search problem can be solved through binary and other methods, which can avoid a large number of traversal calculations.

height: 10 20 30 40  50  60  ...
cache:  10 30 60 100 150 210 ...

One question every day

  • /WindrunnerMax/EveryDay

refer to

  • /post/7232856799170805820
  • /zh-CN/docs/Web/API/IntersectionObserver
  • /react/components/list#Infinite long list
<Previous Next>