MobX: избегайте повторного рендеринга, когда ключи объектов не используются в представлениях

Question

У меня есть список наблюдаемых объектов:

[
    {
        key1: "x",
        updateTs: "y"
    },

    ...
]

Пользователь может изменять эти объекты с помощью пользовательского интерфейса.

Эти изменения отправляются на удаленный сервер и после возврата запроса«updateTs» обновляется.

Проблема в том, что при подключении к сети это вызывает двойной рендеринг:

1. Первоначальное редактирование из пользовательского интерфейса.

2. Когда удаленный запрос возвращается и редактирует updateTs.

Я не использую updateTs, на мой взгляд, только его родственные ключи (key1).

MobX @observer отслеживает чтение объектов, поэтому он запускает повторный рендеринг.

Это приводит к рывку пользовательского интерфейса, так как он использует процессорное время JS для повторного вычисления виртуального dom и его различий (списокочень большой).

Можно ли избежать второго повторного рендеринга?

Answer 1

Чтобы избежать «рывков», сделайте ваши компоненты Mobx как можно меньше. Например, создайте свой компонент item с субкомпонентом «key» и субкомпонентом «ts» (и сделайте оба субкомпонента observer s). Тогда Mobx должен вызывать только обновление подкомпонентов, а поскольку каждый подкомпонент заботится только об одном свойстве, редактирование одного не должно влиять на другое.

Вы должны будете передать весь «предмет» observable компоненту (как опору), чтобы Mobx мог его правильно отследить. Кроме того, убедитесь, что обновления коллекции элементов и их значений установлены, и не создавайте заново объекты.

Вы правы, что чтение свойства заставляет Mobx отслеживать изменения этого свойства. Поэтому, если вы не хотите, чтобы компонент повторно отображался, вы не должны изменять ничего, что вы читаете из этого компонента. Однако подкомпоненты, которые observer s, отслеживают свойства Mobx в разных контекстах. Поэтому, если вы читаете что-то в дочернем компоненте-наблюдателе, но не в родительском компоненте, Mobx не будет обновлять родительский компонент.

См. Также: Оптимизация Mobx для реакции

Answer 2

Я думаю, вы можете найти ответ здесь жизненный цикл компонента

Выберите один из вариантов, который вам подходит: 1. использует shouldcomponentupdate 2. использует PureComponent