преждевременная оптимизация - зло, имхо

задуматься то никто не мешает

Math.ceil(windowHeight / min(heights))

ммм. так ты не отрендрил же все компоненты)) ты отрендрил 30. 10 посредине, 10 сверху и 10 снизу

да, и?)

а хотя я вообще не понимаю к чему ты это скинул

ты как предлагаешь заранее посчитать размер сообщения?

самая простая стратегия понять, сколько сообщений влазит в экран

так ты не поймешь сколько влазит

одно сообщение такое

так поэтому взяли минимум, пускай рендерится на 5 больше сообщений

другое вот такое длинное при длинное сори за такую фигню в чате))

всяко лучше тысячи)

так ты react-virtualized должен сказать не высоту блока

а высоту 1 item в списке

Так это же текст, какая разница какая у него высота, ты знаешь что минимальный размер сообщения 10 пикселей, ну и от этого отталкиваешься

Она динамичная может быть

https://github.com/orgsync/react-list#type-one-of-simple-variable-or-uniform-defaults-to-simple variable This type is preferred when the sizes of the items in the list vary. Supply the itemSizeGetter when possible so the entire length of the list can be established beforehand. Otherwise, the item sizes will be cached as they are rendered so that items that are above the viewport can be removed as the list is scrolled.

надо внимательнее посмотреть. Я знаю что есть как минимум два чатика на реакте и там не используются виртуальные списки для сообщений. Мне этого хочется, но пока не представляю как это хорошо сделать

короче, по поводу преждевременного. Ты можешь предпологать заранее, что компонент будет часто меняться или много использоваться или еще чего. Вот только это по итогу может и не стать проблемой производительности, а проблемая будет например сжатие png-шки на клиенте :)

Там пачками грузятся сообщения, условно по 50 штук 3 блока, как только еще 50 надо загрузить первый блок кешируется и удаляется из дома

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

но если чего-то можно избежать заранее - лучше этого избежать)

Ты де не знаешь чего можно избежать заранее, требования постоянно меняются, и ты должен поддерживать уже оптимизацию и сам компонент

Не нужно ничего делать пока это не тормозит

this ^

я и согласен и не согласен))

Ты станешь единичные компоненты оптимизировать? Например обертку над инпут?

Ты станешь единичные компоненты оптимизировать? Например обертку над инпут?

ага. вот ща занимаюсь разработкой библиотеки компонентов в проект. Ток что добавил везде sCU. Мне не влом там это поддерживать

А теминг делаешь?

у компонентов? не у всех. У всех стараюсь дать className просунуть

а если больше 1 класса надо передать ?

и в чем проблема?

сделаешь 10 пропсов ?

в этом наверное

значит дробить компонент надо, если 10 пропсов на классы

вообще не так

дропдаун например

контейнер, выпадающий контейнер, строка - уже 3

ну строка и контейнер прямо заранее разные компоненты

с чего бы это когда это компонент с дроп дауном

какой смысл в такой библиотеке тогда когда ты ее локально собираешь по частям

для ясного примера можно взять реакт-селект

эм, ну такой интерфейс

в котором множество элементов кторые нужно стилизовать

тебя не коробит select-у писать options?

если это нативный селект то нет, если это будет обертка то она будет подразумевать массив с опшенами

если это нативный селект то нет, если это будет обертка то она будет подразумевать массив с опшенами

с чего вдруг?)

что бы не копипастить

для ясного примера можно взять реакт-селект

да, хороший пример. Ужасный компонент

ну таких сейчас 99 процентов

плохо, че)

а твое решение-то какое?

прокидывать пропс в котором будут все классы

как в модулях цсс

это из react-bootstrap

это плохой пример

в котором ты не можешь ничего

не могу ничего что?) Аргументации не хватает

изменить стили выпадалки

хочу что бы не ровные границы были а треугольник вверху

так и что мешает?

нет такой возможности

потому что бутстрап не дает изменить ее стили

значит интерфейс этого не предполагает

ERROR: S client not available

значит в твой проект этот компонент не подойдет)

да

но это не значит, что это плохо) Это значит что у тебя специфичные требования

а если бы он как плохой реакт селект выкидывал мне все пропсы на элементы которые я могу изменить такой проблемы не было бы

gcc js в нативный код не умеет компилировать, от этого gcc не становится плохим компилятором)

если курица не умеет давать молоко это плохая курица

ну вот да, примерно это ты хочешь от специфичного для моего проекта реакт-компонента)

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

если в каждом проекте мне нужно лезть в нее и допиливать под конкретный случай - это плохая библиотека

Абстрактная да, UI кит конкретного проекта - для реюзабельности компонент внутри проекта и вполне может быть завязан на конкретный дизайн

у нас библиотека компонентов создается чтобы использовать ее внутри проекта, а не для всех возможных проектов

кстати что думаете над вынесением не просто ui-kit для проекта, а вообще всего интерфейса. Только тупые компоненты, естественно, никакой бизнес логики.

@gusnkt а есть возможность посмотреть ее на гитхабе?

Более того - могут быть несколько проектов в единой стилистике

То есть форма логина, аватарка, инпут

Я в своем проекте в компонентах только такие и держу

@gusnkt а есть возможность посмотреть ее на гитхабе?

https://github.com/dialogs/dialog-web-components

кстати что думаете над вынесением не просто ui-kit для проекта, а вообще всего интерфейса. Только тупые компоненты, естественно, никакой бизнес логики.

мне нравится идея распиливать проект на несколько библиотек. легче поддерживать

можно тестировать независимо и улучшать

и меньше приязано к общему релизному циклу

да, вот мне тоже эта идея очень нравится) еще пока сыро, но потихоньку будет вообще круто)

на material-ui похоже

это пока, там нет дизайна проекта еще. И пока только совсем базовые контролы, а мысль большие тупые компоненты вынести, как уже сказал. Форма логина, сообщение, список сообщений

ну вполне ок

я похожей штукой занимаюсь просто

попапы боль приносят немного

Ах да. Дизайнер когда нарисует все, будет проще ему контролировать соблюдение этого дизайна)

но в целом ок

а насколько оправданно свой https://github.com/dialogs/dialog-web-components/blob/master/src/components/Button/Button.js#L24-L30 реализовывать?

так или иначе с новым реактом будет белые списки пихать

т.е. ничего лишнего

Эм, а не наоборот?