Профит от как минимум меньшего количества кода, вроде как тоже не последнее дело в общем итоге.
Практически все статьи, что мне встречались по этому поводу советуют все-таки «разумно» использовать PureComponent. В любом случае ради интереса было бы интересно увидеть на практике в сравнении рендер двух больших списков в разных вариациях.
Кажется я понял. Вы имеете ввиду, что если использовать вместо PureComponent не Component, а просто функцию (ака stateless notation)?
Верно, комментарий изначально вроде был именно о них.
А разве это не упрощённая запись Component?
На сколько я знаю, это одна из «фичей» функциональных компонентов, что они опускают всякую всячину вроде хуков. По крайней мере сравнение транспиленного объявления этих компонентов говорит о наличии какой-то разницы)
var A = function (_React$Component) {
_inherits(A, _React$Component);
function A() {
_classCallCheck(this, A);
return _possibleConstructorReturn(this, (A.__proto__ || Object.getPrototypeOf(A)).apply(this, arguments));
}
_createClass(A, [{
key: "render",
value: function render() {
return React.createElement("div", null);
}
}]);
return A;
}(React.Component);
var B = function B() {
return React.createElement("div", null);
};
Честно говоря чтоб сказать однозначно — надо потестить, мне как-то никогда в голову не приходило (либо не было надобности) использовать PureComponent на каждом компоненте, если есть эта проверка на тех компонентах, которые, допустим, рендерят большие списки, то проверять еще каждый элемент этого списка — помоему лишняя операция сравнения в процессе апдейта. В случае если вы на 80+% уверены что компонент не будет ререндериться, тогда уж проще просто вернуть false из shouldComponentUpdate. К тому же не забывайте о том что при использовании PureComponent, если компонент все-таки будет обновляться — будут вызываться все lifecycle hooks компонента, которые Вам (возможно) в данном случае не нужны.
Если бы это работало лучше, каждый компонент в реакте был бы pure по дефолту. Достаточно часто операция поверхностного сравнения для тупого компонента будет дороже чем выполнение рендера самого компонента, особенно если мы говорим о мелких атомарных компонентах, которые отвечают за рендер небольшого участка дома. Поэтому, но мой взгляд это не совсем верно. Это как прописывать shouldComponentUpdate в каждом компоненте (до появления pureConponent), вряд ли Вы так делали.
При таком раскладе само собой. Но все надо делать с умом) из Вашего комментария, я так понял что Вы имеете в виду вообще отказаться от их использования.
Практически все статьи, что мне встречались по этому поводу советуют все-таки «разумно» использовать PureComponent. В любом случае ради интереса было бы интересно увидеть на практике в сравнении рендер двух больших списков в разных вариациях.
Верно, комментарий изначально вроде был именно о них.
На сколько я знаю, это одна из «фичей» функциональных компонентов, что они опускают всякую всячину вроде хуков. По крайней мере сравнение транспиленного объявления этих компонентов говорит о наличии какой-то разницы)
Вот нашел твит Абрамова на этот счет
twitter.com/dan_abramov/status/759383530120110080
А можно по подробнее почему не стоит использовать stateless components без recompose? И почему они просаживают производительность?