Comments 5
Прежде чем бежать и убирать анонимные функции renderItem стоит узнать «насколько часто обновляется весь список»… очень часто он не обновляется вообще и это бесполезная оптимизация.
Хорошое замечания, но судя по моим наблюдениям в 97% случаев это так, и если не сам список изменяется то какой-то стейт или пропс обязательно изменится в ходе работы приложения и этим дернет рендер
Приведите примеры, если не сложно. У меня ecommerce тематика и там...
- страницы каталога не обновляются во время работы (главная, категории, поиск)
- другие страницы тип истории заказов аналогично
- изменение количества товара не перерисовывает список корзины (только добавление, но там 20-30 позиций макс и смысла что-то оптимизировать нет)
- списков с галками больше чем на 20-30 элементов с checkbox я тоже не видел, это странный ux.
Просто интересно в каком типе приложений постоянно обновляются списки, чтобы в будущем быть готовым.
Во вторых код смотрится неаккуратно
Весьма субъективно. Порой, чтобы вынести подобные конструкции в отдельный компонент, требуется на порядок больше кода, чем просто заинлайнить (вы же используете TypeScript или PropTypes?).
Почему бы не сделать так
К части «или так»: лучше, но вы потеряли объект item.
А именно не использовать анонимную функцию для рендеринга внутри .map.
Это важно при передаче функций в props, поскольку тогда (если компонент мемоизирован стандартными средствами) каждый ре-рендер будет новая ссылка на функцию. В контексте Array.prototype.map это не имеет инкакого значения.
И последний шаг который мы можем сделать это использовать так называемый PureComponent для рендеринга каждого item
Спорно. Порой это только повышает расход ресурсов (процессор и память), а порой лучше мемоизировать компонент, который рендерит сам список.
И пожалуйста не используйте для этого index элемента в массиве. Ниже я расскажу почему.
И не рассказали. Нельзя так с читателем.
Для страждущих: key нужен Реакту для того, чтобы корректно запускать методы жизненного цикла для появляющихся и исчезающих из списка компонентов.
Это, конечно, лучше, чем обычная лапша, где об оптимизации даже не задумывались, но всё жи слишком много безаппеляционных утверждений.
С некоторыми замечаниями готов поспорить
Да, TypeScript использую намного чаще чем PropTypes
Все же есть общепринятые стандарты которых лучше придерживаться для улучшения читаемости кода
Тут все зависит от ситуации и что то общее тяжело советовать
Здесь согласен, действительно пока дописал до конца статьи уже и забыл что обещал написать)))
Весьма субъективно. Порой, чтобы вынести подобные конструкции в отдельный компонент, требуется на порядок больше кода, чем просто заинлайнить (вы же используете TypeScript или PropTypes?).
Да, TypeScript использую намного чаще чем PropTypes
Все же есть общепринятые стандарты которых лучше придерживаться для улучшения читаемости кода
Спорно. Порой это только повышает расход ресурсов (процессор и память), а порой лучше мемоизировать компонент, который рендерит сам список.
Тут все зависит от ситуации и что то общее тяжело советовать
И не рассказали. Нельзя так с читателем.
Для страждущих: key нужен Реакту для того, чтобы корректно запускать методы жизненного цикла для появляющихся и исчезающих из списка компонентов.
Здесь согласен, действительно пока дописал до конца статьи уже и забыл что обещал написать)))
Sign up to leave a comment.
Рендеринг списков в React Native