Pull to refresh

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-classes :) прекрасная штука, очень удобно работать в т.ч. с модификаторами, плюс миксовать блоки и элементы.

Ну почти переизобрел (Библиотека не моя, просто пользуюсь. Только декоратор самописный). Мне кажется, 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.
Например когда я делал мок данных которые потом буду приходить с сервера с уникальными ID.
1КБ на дороге не валяется!
P.S. спасибо, никогда не смотрел в сторону lodash, так как приятель сказал, что ramda ramda ramda
Не 2, а 2.2K — 1.2K = 1K.
А если в сжатом виде 915 — 638 = 277
Внимательно прочитайте ещё раз мой первый коммент.
Имея оверхед в 277 байт — я не буду подключать ради их экономии более лёгкую библиотеку.
Допустим tree shaking работает как надо.
Опечатался, прошу прощения.
Про размер ирония была(часто иронизирую про размер), конечно, если используете lodash, в nanoid смысла никакого нет
А я про Ramda никогда не слышал.
Библиотека для функционального программирования на JS. Много интересных штук, позволяет писать чистый код (описание многих ФП библиотек на JS)
Я посмотрел, буду иметь в виду. Мне непонятна реакция на мой комментарий.
Как будто это преступление какое — чего-то не знать. Сразу вон из профессии, как уже писали выше.
А чем Math.random не угодил? Для цели генерации случайных ключей в реактовском списке (вон из профессии!) полностью подходит — шанс повторения ничтожно мал, все генерируемые значения можно считать уникальными. Экономия в 638 (915) байт.
Nanoid, что за бред? Убить всю производительность React, пусть тормозит, процы ныне мощные, надо чем-то нагружать? Тут я бы ещё понял, если эта либа вычисляла хэш для объекта, а случайное число, это уже полный бред.
UFO just landed and posted this here
Пугает, что кто то еще ставит + к рейтингу для этой статьи…

Что характерно — автор критику прочитал… и забил :)

Поясните, что за нужда генерить id на клиенте? Разве они не должны приходить с бэка (в приложении здорового человека)? И вроде логика общая такова: существующая в хранилище модель уже имеет id, если модель создается на клиенте — id у нее нет и он появляется при сохранении в DAL. Зачем вообще какие-то ключи на фронте генерить??

Поясните, что за нужда генерить id на клиенте? Разве они не должны приходить с бэка (в приложении здорового человека)?

Сущности, которые нужно перебирать, могут вообще никак не быть связанными с backend-ом. Я даже больше скажу — не всякое приложение вообще требует backend-а.

По поводу classnames есть альтернатива которая работает производительнее: html-classes, вот тест
Sign up to leave a comment.

Articles