Comments 25
Статья немного не формата хабра, но ладно… Немного моих мыслей.
Замечание по поводу первой библиотеки: использовать в списках ее категорически нельзя. Это может очень плохо сказаться на производительности, особенно на больших списках, т.к. ReactJS будет пересоздавать элементы на каждый чих. Тогда уж лучше вообще ключи не использовать, чем рандомные. На крайний случай, индекс массива, хотя это тоже не рекомендуется. А лучше всего использовать статичные IDшники, либо, как в Вашем примере, сам элемент:
import React from 'react'
const ListDrinks = props => {
const drinks = ['rum','bear','vodka']
return(
<ul>
{drinks.map((value)=>{
return(
<li key={value}>{value}</li>
)
})}
</ul>
)
}
export default ListDrinks
Если говорить про библиотеку для генерации классов, то я использую эту. Люблю BEM. Написал обертку-декоратор для этой либы, который можно использовать примерное так:
import React from 'react';
import bemHelper from './bemHelper';
@bemHelper('timeline')
export default class Timeline extends React.PureComponent {
render() {
const {
bemHelper
} = this.props;
return <div className={bemHelper()}>
<div className={bemHelper('element', 'modifier')}></div>
</div>;
}
}
Просто нереально удобно // Знаю про CSS-in-JS, но у нас используется SCSS со всеми вытекающими
Для форм использую react-form. Он немного сложен, но гибок и удобен.
На крайний случай, индекс массива, хотя это тоже не рекомендуется
Народ наткнувшись на это "не рекомендуется" начинает бояться так делать, и начинает городить чёрт знает что. Топик-стартер вот генерирует новые ID при каждом render-е. А один мой коллега очень сильно извратил кодовую базу, добавляя ID в статичные списки сущностей.
На самом же деле надо просто понять проблему. И тогда оказывается, что в ряде случаев использование индекса в массиве в качестве key очень даже уместно. По сути, если:
- у наших перечисляемых объектов нет своего ID и никакая комбинация из этих полей не может быть уникальной.
- в списке невозможны вставки, удаления, перемещения. Сами элементы могут вполне изменяемыми, но вот их взаимное расположение должно быть статичным.
… то мы можем смело использовать key={index}
ни о чём не переживая. По правде говоря, даже не удовлетворяя этим двум пунктам иногда можно использовать key={index}
, но это уже совсем другая история (с).
P.S. автор статьи по вашей ссылке не прав в пункте "the list and items are static–they are not computed and do not change" + "When all of them are met, you may safely use the index as a key.". Потому что "items" совершенно не обязательно должны быть статичными.
Ну почти переизобрел (Библиотека не моя, просто пользуюсь. Только декоратор самописный). Мне кажется, react-bem-helper немного более гибкий. По крайней мере я не заметил в Вашей библиотеке подобных конструкций:
bemHelper('element', {
mod1: true,
mod2: false,
mod3: function() { return false; }
'mod5 mod6': function() { return true; }
});
Для меня замыкания не столь необходимы, но вот передавать объект с модификаторами, где все контролируется Boolean значениями, это просто мегаудобно. Прям как доктор прописал.
Посмотрите в сторону этой библиотеки. Там много чего интересного есть. А декоратор написать не сложно.
Она не моя, просто остановился на ней, когда выбирал.
this.element('element', {
mod1: true,
mod2: false,
mod3: "with-value",
});
вот так работает, т.е. модификаторы либо булевы, либо со значением. В документации нет примера с модификаторами элемента, только пример с блоком, но работает так же (сама возможность передавать модификаторы объектом описана). Передачи коллбэка, вроде как, нет, и ИМХО это был бы лишний функционал.
Того что есть хватает за глаза. Подметил просто, что react-bem-helper
с декоратором стал похож на react-bem-classes
.
А что вы хотели показать примером для Nanoid
? Вы всякий раз генерируете новый ID для элементов списка. Чего ради? По сути вы показываете React, что у вас всякий раз НОВЫЕ элементы. React не соотносит их со старыми instance-ми компонент, а генерирует новые. Полностью с нуля формирует всё, что касается VDom. Всякий раз. Даже если не поменялось вообще ничего. Зачем?
Например когда я делал мок данных которые потом буду приходить с сервера с уникальными ID.
P.S. спасибо, никогда не смотрел в сторону lodash, так как приятель сказал, что ramda ramda ramda
А если в сжатом виде 915 — 638 = 277
Внимательно прочитайте ещё раз мой первый коммент.
Имея оверхед в 277 байт — я не буду подключать ради их экономии более лёгкую библиотеку.
Допустим tree shaking работает как надо.
Поясните, что за нужда генерить id на клиенте? Разве они не должны приходить с бэка (в приложении здорового человека)? И вроде логика общая такова: существующая в хранилище модель уже имеет id, если модель создается на клиенте — id у нее нет и он появляется при сохранении в DAL. Зачем вообще какие-то ключи на фронте генерить??
4 библиотеки, упрощающие жизнь React-разработчика