Keys in React. Готовим правильно29.03.2018 12:33

oldTree:

  


// MyComponent будет удален и создан заново

newTree:

  

Аналогично работает и с React-компонентами:

// В этом примере будет выведено:
// did mount
// will unmount
// did mount

// То есть при смене родителя, MyComponent вначале будет удален,
// а затем создан новый инстанс MyComponent. 
class MyComponent extends PureComponent {
  componentDidMount() {
    console.log("did mount");
  }
  componentDidUpdate() {
    console.log("did update");
  }
  componentWillUnmount() {
    console.log("will unmount");
  }
  render() {
    return 
123
;
  }
}

class A extends Component {
  render() {
    return ;
  }
}

class B extends Component {
  render() {
    return ;
  }
}

class App extends Component {
  state = {
    test: A
  };
  componentDidMount() {
    this.setState({test: B});
  }
  render() {
    var Component = this.state.test;
    return (
        
    );
  }
}

render(, document.getElementById("root"));

2) Массивы элементов сравниваются поэлементно, т. е. реакт одновременно итерируется по двум массивам и сравнивает элементы попарно. Поэтому мы и получили перерисовку всех элементов в списке в примере с именами выше. Разберем на примере:

// oldTree

  
Паша
  
Саша


// newTree

  
Паша
  
Саша
  
Гриша

Реакт вначале сверит

В случае же, когда добавляем элемент вверх:

// oldTree

  
Паша
  
Саша


// newTree

  
Гриша
  
Паша
  
Саша

Реакт сравнит

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

// oldTree

  
Паша
  
Саша


// newTree

  
Гриша
  
Паша
  
Саша

Реакт найдет key='1', key='2', определит, что c ними не произошло изменений, и затем найдет новый элемент

Перепишем наш пример, добавив ключи. Обратите внимание, что теперь при добавлении элементов вверх списка происходит создание только одного компонента:

Замечу, что мы добавили id к нашим именам и управляем keys напрямую, не используя индекс элемента в массиве как key. Это обусловлено тем, что при добавлении имени в верх списка индексы поедут.

Подведем итог первой части:

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

Реиспользование ключей и нормализация

Усложним задачу. Теперь создадим список не абстрактных людей, а список людей — членов команды разработки. В компании две команды. Члена команды можно выделить по клику мышки. Попробуем решить задачу «в лоб». Попробуйте выделять людей и переключаться между командами:

import React, { Component, PureComponent, Fragment } from "react";
import { render } from "react-dom";
import "./style.css";

class App extends Component {
  state = {
    active: 1,
    teams: [
      {
        id: 1,
        name: "Amazing Team",
        developers: [
          { id: 1, name: "Миша" },
          { id: 2, name: "Екатерина" },
          { id: 3, name: "Валерий" }
        ]
      },
      {
        id: 2,
        name: "Another Team",
        developers: [
          { id: 1, name: "Саша" },
          { id: 2, name: "Даниил" },
          { id: 3, name: "Марина" }
        ]
      }
    ]
  };
  addTop = name => {
    this.setState(state => ({
      teams: state.teams.map(
        team =>
          team.id === state.active
            ? {
                ...team,
                developers: [
                  { id: team.developers.length + 1, name },
                  ...team.developers
                ]
              }
            : team
      )
    }));
  };
  addBottom = name => {
    this.setState(state => ({
      teams: state.teams.map(
        team =>
          team.id === state.active
            ? {
                ...team,
                developers: [
                  ...team.developers,
                  { id: team.developers.length + 1, name }
                ]
              }
            : team
      )
    }));
  };
  toggle = id => {
    this.setState(state => ({
      teams: state.teams.map(
        team =>
          team.id === state.active
            ? {
                ...team,
                developers: team.developers.map(
                  developer =>
                    developer.id === id
                      ? { ...developer, highlighted: !developer.highlighted }
                      : developer
                )
              }
            : team
      )
    }));
  };
  switchTeam = id => {
    this.setState({ active: id });
  };
  render() {
    return (
      
        
         team.id === this.state.active)
              .developers
          }
        />
        
      
    );
  }
}

class TeamsSwitcher extends PureComponent {
  render() {
    return (
      

        {this.props.teams.map(team => (
          
 {
              this.props.onSwitch(team.id);
            }}
            key={team.id}
          >
            {team.name}
          
        ))}
      
    );
  }
}

class AddName extends PureComponent {
  getInput = el => {
    this.input = el;
  };
  addToTop = () => {
    if (!this.input.value.trim()) {
      return;
    }
    this.props.addTop(this.input.value);
    this.input.value = "";
  };
  addToBottom = () => {
    if (!this.input.value.trim()) {
      return;
    }
    this.props.addBottom(this.input.value);
    this.input.value = "";
  };
  render() {
    return (
      
        
        Add to TOP
        Add to BOTTOM
      
    );
  }
}

class Users extends PureComponent {
  render() {
    return (
      

        {this.props.names.map(user => (
          
            {user.name}
          
        ))}
      
    );
  }
}

class Name extends PureComponent {
  render() {
    return (
      
 this.props.onClick(this.props.id)}
      >
        {this.props.children}
      
    );
  }
}

render(, document.getElementById("root"));

Заметим неприятную особенность: если выбрать человека и затем переключить команду, произойдет анимирование снятия выделения, хотя человек в другой команде никогда мог и не быть выделен. Вот яркий пример на видео:

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

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

В приведенном коде есть пара проблем:

1. Данные не нормализованы, работа с ними усложняется.
2. Происходит дублирование ключей у сущности developer, из-за чего реакт не пересоздает компонент, а обновляет его. Это и ведет к сайд-эффектам.

Решить проблему можно двумя путями. Простым решением будет создать составной ключ для разработчиков в формате: ${id команды}.${id разработчика}, это позволит не пересекаться ключам и избавиться от сайд-эффектов.

Но проблему можно решить комплексно, нормализовав данные и объединив сущности. Значит, в state компонента будет 2 поля: teams, developers. developers будут содержать мапу id + name, teams будут иметь список разработчиков, которые находятся в команде. Реализуем это решение:

class App extends Component {
  state = {
    active: 1,
    nextId: 3,
    developers: {
      "1": { name: "Миша" },
      "2": { name: "Саша" },
    },
    teams: [
      {
        id: 1,
        name: "Amazing Team",
        developers: [1]
      },
      {
        id: 2,
        name: "Another Team",
        developers: [2]
      }
    ]
  };
  addTop = name => {...};
  addBottom = name => {...}
  toggle = id => {
    this.setState(state => ({
      developers: {
        ...state.developers,
        [id]: {
          ...state.developers[id],
          highlighted: !state.developers[id].highlighted
        }
      }
    }));
  };
  switchTeam = id => {...};
  render() {
    // При реальной разработке вычисление списка людей лучше мемоизировать или вынести в computed value и хранить в state
    return (
      
        
         team.id === this.state.active)
            .developers.map(id => ({ id, ...this.state.developers[id] }))}
        />
        
      
    );
  }
}

import React, { Component, PureComponent, Fragment } from "react";
import { render } from "react-dom";
import "./style.css";

class App extends Component {
  state = {
    active: 1,
    nextId: 7,
    developers: {
      "1": { name: "Миша" },
      "2": { name: "Екатерина" },
      "3": { name: "Валерий" },
      "4": { name: "Саша" },
      "5": { name: "Даниил" },
      "6": { name: "Марина" }
    },
    teams: [
      {
        id: 1,
        name: "Amazing Team",
        developers: [1, 2, 3]
      },
      {
        id: 2,
        name: "Another Team",
        developers: [4, 5, 6]
      }
    ]
  };
  addTop = name => {
    this.setState(state => ({
      developers: { ...state.developers, [state.nextId]: { name } },
      nextId: state.nextId + 1,
      teams: state.teams.map(
        team =>
          team.id === state.active
            ? {
                ...team,
                developers: [state.nextId, ...team.developers]
              }
            : team
      )
    }));
  };
  addBottom = name => {
    this.setState(state => ({
      // установку developers и nextId можно вынести в отдельную функцию, чтобы не дублировать код
      developers: { ...state.developers, [state.nextId]: { name } },
      nextId: state.nextId + 1,
      teams: state.teams.map(
        team =>
          team.id === state.active
            ? {
                ...team,
                developers: [...team.developers, state.nextId]
              }
            : team
      )
    }));
  };
  toggle = id => {
    this.setState(state => ({
      developers: {
        ...state.developers,
        [id]: {
          ...state.developers[id],
          highlighted: !state.developers[id].highlighted
        }
      }
    }));
  };
  switchTeam = id => {
    this.setState({ active: id });
  };
  render() {
    // При реальной разработке вычисление списка людей лучше мемоизировать или вынести в computed value и хранить в state
    return (
      
        
         team.id === this.state.active)
            .developers.map(id => ({ id, ...this.state.developers[id] }))}
        />
        
      
    );
  }
}

class TeamsSwitcher extends PureComponent {
  render() {
    return (
      

        {this.props.teams.map(team => (
          
 {
              this.props.onSwitch(team.id);
            }}
            key={team.id}
          >
            {team.name}
          
        ))}
      
    );
  }
}

class AddName extends PureComponent {
  getInput = el => {
    this.input = el;
  };
  addToTop = () => {
    if (!this.input.value.trim()) {
      return;
    }
    this.props.addTop(this.input.value);
    this.input.value = "";
  };
  addToBottom = () => {
    if (!this.input.value.trim()) {
      return;
    }
    this.props.addBottom(this.input.value);
    this.input.value = "";
  };
  render() {
    return (
      
        
        Add to TOP
        Add to BOTTOM
      
    );
  }
}

class Users extends PureComponent {
  render() {
    return (
      

        {this.props.users.map(user => (
          
            {user.name}
          
        ))}
      
    );
  }
}

class Name extends PureComponent {
  render() {
    return (
      
 this.props.onClick(this.props.id)}
      >
        {this.props.children}
      
    );
  }
}

render(, document.getElementById("root"));

Теперь элементы обрабатываются корректно:

Нормализация данных упрощает взаимодействие с дата-слоем приложения, упрощает структуру и уменьшает сложность. Например, сравните функцию toggle с нормализованными и ненормализованными данными.

Hint: Если бекенд или api отдает данные в ненормализованном формате, нормализовать их можно с помощью — https://github.com/paularmstrong/normalizr

Подведем итог второй части:

При использовании ключей важно понимать, что при смене данных ключи должны меняться. Яркий пример ошибок, которые я встречал во время ревью, использование индекса элемента в массиве как key. Это приводит к сайд-эффектам типа того, что мы рассматривали на примере отображения списка людей с выделением.

Нормализация данных и/или составные key позволяют добиться нужного эффекта:

1. Обновляем данные, когда изменяется сущность (например, помечается выделенной или мутирует).
2. Удаляем старые инстансы, если элемента с заданным key больше не существует.
3. Создаем новые элементы, когда это нужно.

Использование key при рендере одного элемента

Как мы обсуждали, реакт при отсутствии key сравнивает элементы старого и нового дерева попарно. При наличии ключей — ищет в списке children нужный элемент с заданным ключом. Случай, когда children состоит только из одного элемента, не исключение из правила.

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

class Notification1 extends PureComponent {
  componentDidMount() {
    setTimeout(() => {
      this.element && this.element.classList.add("notification_hide");
    }, 3000);
  }
  render() {
    return (
      
 (this.element = el)} className="notification">
        {this.props.children}
      
    );
  }
}

Да, в этом компоненте нет обратной связи, он не вызывает никаких onClose, но для этой задачи не важно.

Мы получили простой компонент.

Представим ситуацию — при клике на кнопку отображается подобная нотификация. Пользователь кликает на кнопку не переставая, но уже через три секунды нотификации добавится класс notification_hide, и она станет невидимой пользователю (если мы не использовали key).

Чтобы исправить работу компонента без использования key, создадим класс Notification2, который с помощью lifeCycle-методов будет корректно обновляться:

class Notification2 extends PureComponent {
  componentDidMount() {
    this.subscribeTimeout();
  }
  componentWillReceiveProps(nextProps) {
    if (nextProps.children !== this.props.children) {
      clearTimeout(this.timeout);
    }
  }
  componentDidUpdate(prevProps) {
    if (prevProps.children !== this.props.children) {
      this.element.classList.remove("notification_hide");
      this.subscribeTimeout();
    }
  }
  subscribeTimeout() {
    this.timeout = setTimeout(() => {
      this.element.classList.add("notification_hide");
    }, 3000);
  }
  render() {
    return (
      
 (this.element = el)} className="notification">
        {this.props.children}
      
    );
  }
}

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

Но решить задачу можно, и используя наш первый компонент Notification1 и атрибут key. У каждой нотификации есть свой уникальный id, которым мы воспользуемся как key. Eсли при изменении нотификации изменяется key, то Notification1 будет пересоздаваться. Компонент будет соответствовать нужной бизнес-логике:

Таким образом

В редких случаях использование key при рендере одного компонента оправданно. key — очень мощный способ «помогать» механизму reconciliation понимать, нужно ли сравнивать компоненты или стоит сразу же (пере)создать новый.

Работа с ключами при передаче компоненту children

Интересная особенность key — он недоступен в самом компоненте. Это происходит потому, что key — special prop. В React существует 2 специальных props: key и ref:

class TestKey extends Component {
  render() {
    // Выведет в консоли null
    console.log(this.props.key);
    // div будет пустым
    return 
{this.props.key}
;
  }
}

const App = () => (
  

    
  
);

Кроме того, в консоли будет warning:

Warning: TestKey: key is not a prop. Trying to access it will result in undefined being returned. If you need to access the same value within the child component, you should pass it as a different prop. (https://fb.me/react-special-props)

Но, если компоненту передали children, у которых есть key, вы сможете с ними взаимодействовать, но поле key будет не внутри объекта props, а на уровне самого компонента:

class TestKey extends Component {
  render() {
    console.log(this.props.key);
    return 
{this.props.key}
;
  }
}

class TestChildrenKeys extends Component {
  render() {
    React.Children.forEach(this.props.children, child => {
      // Доступ к key можно получить внутри child, при итерировании.
      // Как правило, такой хак может пригодиться только в исключительных ситуациях
      // Не нужно завязываться на key таким образом
      // Лучше задублировать ключ в другом prop
      console.log(child.key);

      // Все остальные props, кроме key и ref будут переданы в объекте props
      console.log(child.props.a);
    });
    return this.props.children;
  }
}

const App = () => (
  

    
      
      
      
      
    
  
);

Консоль выведет:

1
prop1
2
prop2
3
prop3
10
prop10

Подытожим:

key и ref — special props в реакте. Они не включаются в объект props и недоступны внутри самого компонента.

Получить доступ к child.key или child.ref можно из родительского компонента, которому передали children, но делать этого не нужно. Практически нет ситуаций, когда это нужно. Всегда можно решить задачу проще и лучше. В случае если нужен key для обработки в компоненте — задублируйте его, например в prop id.

Мы рассмотрели области применения key, как он передается в компонент, каким образом изменяется механизм reconciliation с заданием key и без него. А также посмотрели на использование key для элементов, которые являются единственным child. Сгруппируем в конце основные тезисы:

1. Без key механизм reconciliation сверяет компоненты попарно между текущим и новым VDOM. Из-за этого может происходить большое количество лишних перерисовок интерфейса, что замедляет работу приложения.

   
   

2. Добавляя key, вы помогаете механизму reconciliation тем, что с key он сверяет не попарно, а ищет компоненты с тем же key (тег / имя компонента при этом учитывается) — это уменьшает количество перерисовок интерфейса. Обновлены/добавлены будут только те элементы, которые были изменены/не встречались в предыдущем дереве.

   
   

3. Следите, чтобы не появлялись дублирующие key, при переключении отображения у новых данных не совпадали ключи. Это может привести к нежелательным сайд-эффектам, таким как анимации, или некорректной логике поведения элемента.

   
   

4. В редких случаях key используют и для одного элемента. Это сокращает размер кода и упрощает понимание. Но область применения этого подхода ограничена.

   
   
5. key и ref — специальные props. Они недоступны в компоненте, их нет в child.props. Можно получить доступ в родителе через child.key, но реальных областей применения для этого практически нет. Если в дочерних компонентах нужен key — правильным решением будет задублировать в prop id, например.

© Habrahabr.ru