Ленивая загрузка длинных страниц React — динамический рендеринг компонентов

React.js HTML

задний план

Длинные страницы очень распространены во фронтенд-разработке. Например, на главной странице электронной коммерции на рисунке ниже данные об этажах поступают из конфигурации оператора в фоновом режиме, количество этажей не является фиксированным, и каждый этаж может зависеть от большего количества данных о перелистывании страниц. В этом случае, если страница отображается сразу, вполне возможно, что это повлияет на эффективность нашей страницы (fmp, fid).

Для лучшего взаимодействия с пользователем нам нужно рассмотреть компоненты, которые отображают следующий экран, когда пользователь прокручивает до следующего экрана.

image.png

Идеи дизайна

Предположим, что страница должна отображать n компонентов, каждый из которых инициирует запросы к другим интерфейсам. При разработке такой длинной страницы мы в основном сталкиваемся со следующими двумя проблемами:

  • Как оценить время рендеринга следующего компонента экрана?
  • В процессе многократного обновления данных, как предотвратить повторную инициацию компонентом запросов данных?

фигура 1

1. Время отрисовки следующего экрана

  1. первоначальное определение

Взяв в качестве примера домашнюю страницу, мы сохраняем источник данных пола с помощью переменной homeInfo и сохраняем фактические отображаемые данные с помощью compList. Кроме того, нам нужен загрузочный компонент, который всегда находится внизу компонента пола.

const homeInfo = [...楼层数据];
const [compList, setCompList] = useState([]); // 渲染的组件数据
const bottomDomRef = useRef<HTMLDivElement>(null);
// 楼层组件
<div>
   {compList.map((homeItem, index) => (
     <div className="home-floor" key={index}>
         // 根据不同的楼层渲染不同的楼层组件
        {renderHomeConfig(homeItem)}
      </div>
   ))}
</div>

// loading DOM
<div ref={bottomDomRef} className='bottom-loading'>
  <Icon name="loading" />
</div>

// completed DOM
<div className="bottom-completed">
   <p>已经到底啦</p>
</div>
  1. Находится ли компонент загрузки внутри представления

Как показано на рисунке 1, когда позиция загружаемого компонента прокручивается в поле зрения, и если в это время все еще есть неотрендеренные компоненты, пришло время отобразить следующий экран.

Есть два способа определить, находится ли компонент в представлении, один из них — вызвать методElement.getBoundingClientRect()метод для получения информации о границах элемента загрузки и вынесения суждений, а другой - вызватьIntersection Observer APIвынести приговор.

Способ 1: getBoundingClientRect

Нам нужно знать высоту окна и высоту компонента загрузки.

Element.clientHeight Высота внутри элемента, включая отступы, но исключая горизонтальные полосы прокрутки, границы и поля.

Element.scrollHeight Мера высоты содержимого элемента, включая содержимое, невидимое из-за переполнения.

Метод Element.getBoundingClientRect() возвращает размер элемента и его положение относительно окна просмотра.

const scrollRenderHandler = ():void => {
    const rect = bottomDomRef.current?.getBoundingClientRect();
    // top 是loading组件的位置
    const top = rect ? rect.top : 0;
    // 视窗高
    const clientHeight = document.documentElement.clientHeight
                        || document.body.clientHeight;
    if (top < clientHeight &&  组件没渲染完) {
        // 继续渲染
    }
}

 useEffect(() => {
    document.addEventListener('scroll', scrollRenderHandler);
    return (): void => {
      document.removeEventListener('scroll', scrollRenderHandler);
    };
  }, [scrollRenderHandler]);
Метод 2: наблюдатель пересечения

Используйте API-интерфейс react-intersection-observer, чтобы определить, находится ли загружаемый элемент внутри представления.

// Use object destructing, so you don't need to remember the exact order
const { ref, inView, entry } = useInView(options);
// Or array destructing, making it easy to customize the field names
const [ref, inView, entry] = useInView(options);
import { useInView } from 'react-intersection-observer';

const [bottomDomRef, inView] = useInView({
   threshold: 0,
});

const scrollRenderHandler = ():void => {
    if (inView &&  组件没渲染完) {
        // 继续渲染
    }
}
  1. Отрисовывается ли компонент

Предполагая, что 3 компонента отображаются на одном экране, аналогично pageSize = 3 в общей логике разбиения по страницам, мы можем разделить n компонентов на 3 группы по 1, отображать каждую группу по очереди и использовать compGroups для сохранения разделенных групп, а также использовать groupIdx указатель в то же время, чтобы указать на следующую групповую последовательность для рендеринга.

export const splitGroups = (homeList: any[], pageSize: number): any[] => {
  const groupsTemp = [];
  for (let i = 0; i < homeList.length; i += pageSize) {
    groupsTemp.push(homeList.slice(i, i + pageSize));
  }
  return groupsTemp;
};

const compGroups = useMemo(() => splitGroups(homeInfo, 3), [homeInfo]);
const groupCount = compGroups.length;
const [groupIdx, setGroupIdx] = useState(0);

При разделении группы решается проблема, как определить, что компонент не отрендерился.Когда groupIdx меньше, чем groupCount, обновляются compList и groupIdx.

if (top < clientHeight && groupIdx < compGroups.length) {
    setCompList(compList.concat(compGroups[groupIdx]));
    setGroupIdx(groupIdx + 1);

 }
  1. Отслеживание оптимизации прокрутки

Функция scrollRenderHandler часто срабатывает во время прокрутки, что приводит к снижению производительности страницы. На этом этапе вам нужно использовать регулирование и использовать useCallback для кэширования функции scrollRenderHandler для повышения производительности.

const [scrollRenderHandler] = useDebounce((): void => {
    if (inView && groupIdx < groupCount) {
      setCompList(compList.concat(compGroups[groupIdx]));
      setGroupIdx(groupIdx + 1);
    }
  },
  300,
  [compGroups, compList, groupIdx, inView],
 );

 useEffect(() => {
    document.addEventListener('scroll', scrollRenderHandler);
    return (): void => {
      document.removeEventListener('scroll', scrollRenderHandler);
    };
 }, [scrollRenderHandler]);

export default function useDebounce<T extends(...args: any[]) => any>(
  func: T,
  delay: number,
  deps: DependencyList = [],
): [T, () => void] {
  const timer = useRef<number>();
  const cancel = useCallback(() => {
    if (timer.current) {
      clearTimeout(timer.current);
    }
  }, []);

  const run = useCallback((...args) => {
    cancel();
    timer.current = window.setTimeout(() => {
      func(...args);
    }, delay);
  }, deps);
  return [run as T, cancel];
}

2. Не инициируйте повторные запросы данных

  1. ключевой анализ

Пока что по мере прокрутки экрана мы в основном выполнили требования для динамического рендеринга компонентов. Но есть еще одна проблема: при прокрутке один и тот же интерфейс данных запрашивается несколько раз.动图2.gifimage.pngКак показано выше, интерфейс на одном этаже запрашивается дважды. Это означает, что в процессе прокрутки окна мы неоднократно обновляем данные compList, что вызывает повторный рендеринг компонента этажа, а запрос данных для каждого компонента этажа размещается внутри компонента, который связан с уникальным идентификатором uuid связанный с полом, что приводит к дублированию запросов на интерфейс данных.

  1. React.memo

API верхнего уровня React — React

Из вышеизложенного мы знаем, что пока компоненты не рендерятся повторно, проблемы повторных запросов можно избежать.

До появления React.memo с помощью PureComponent можно было добиться эффекта поверхностного сравнения пропсов.Кроме того, мы также можем использовать shouldComponentUpdate для выполнения конкретных сравнений, тем самым уменьшая количество отрисовок компонентов.

В частности: shouldComponentUpdate(nextProps, nextState) И в функциональных компонентах мы можем использовать React.memo, его использование очень простое, как показано ниже. Если вы не передаете areEqual , выполняется поверхностное сравнение свойств. Если он передан, он должен вернуть конкретный результат сравнения true, false .

function MyComponent(props) {
  /* render using props */
}
function areEqual(prevProps, nextProps) {
  /*
  return true if passing nextProps to render would return
  the same result as passing prevProps to render,
  otherwise return false
  */
}
export default React.memo(MyComponent, areEqual);

Поэтому нам нужно только оборачивать компоненты с memo в соответствующие компоненты пола и сравнивать их уникальные идентификаторы uuid.

код показывает, как показано ниже:

import React, { memo } from 'react';
type GoodsRecommedProps = {
    ...其他 props,
    goodsQuery:{
        uuid: '...'
    }
}

const GoodsRecommed: React.FC<GoodsRecommedProps> = (props) => {
    ...
}

const isEqual = (prevProps: GoodsRecommedProps, nextProps: GoodsRecommedProps): boolean => {
  if (prevProps.goodsQuery.uuid !== nextProps.goodsQuery.uuid) {
    return false;
  }
  return true;
};

export default memo(GoodsRecommed, isEqual);

Наконец, посмотрите на эффект, повторного запроса данных действительно нет.

Суммировать

  • React.memo используется для оптимизации производительности компонентов.
  • useCallback в основном используется для кэширования функций в зависимости от обратного вызова первого параметра кэша.

  • useMemo в основном используется для более тонкой оптимизации производительности определенной части компонента в соответствии с возвращаемым значением первого параметра, который зависит от кеша.

В процессе написания обычной длинной страницы, если гнаться только за завершением, будет очень просто, а вот если хочется еще оптимизировать, можно много чего сделать.

использованная литература


Добро пожаловать в "Byte Front End ByteFE" Контактный адрес электронной почты для доставки резюме "tech@bytedance.com"