flag1 значит true.

data.flag1 == 1 ? data.flag2 : data.flag3

ну такие кейсы не захендлит

но как бы в коннекте, мне и не надо такое хендлить

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

а почему он может/должен?

погибать ?

угу, throttle на вход ставим, и уже немного попроще.

у тебя селекторы все равно

кучу раз будут вызываться

как не крути

Вообще на “сложности” селектором можно особо не экономить, хорошо сработавший селектор быстрее Реакта в любом случае. А для “купирования” апдейтов проще ставить “пограничные пункты”, некие зоны перехода из одного стора в другой, где событие onchange срабатывает только если “нужные” значения “для ветки” обновились

Я полгода назад начинал такой делать, но забросил на возможности ручной настройки. YAGNI.

Вообще на “сложности” селектором можно особо не экономить, хорошо сработавший селектор быстрее Реакта в любом случае. А для “купирования” апдейтов проще ставить “пограничные пункты”, некие зоны перехода из одного стора в другой, где событие onchange срабатывает только если “нужные” значения “для ветки” обновились

ну я так и делаю, только вот эти пограничные пункты

приправил еще проверкой

с битовыми масками

т.е есть рут стор, от рут стора идет фичас с одним коннектом, а от фичи идут провайдеры через контекст

Я так маски и не поборол. Не понятно кому и как битики раздавать.

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

2^n

а селекторы имеют комплексные маски

110111

nbg nfrjuj

тип такого

Битики - это некий хэш, от всего что меняется, да так чтобы при изменении какого либо свойства изменения в хэше были минимальные(но были!), но в нем всего 32 дырочки, а данных - мнноооого

Битики - это некий хэш, от всего что меняется, да так чтобы при изменении какого либо свойства изменения в хэше были минимальные(но были!), но в нем всего 32 дырочки, а данных - мнноооого

а тебе большой нестинг и не нужно хендлить

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

а 30 пропертей этого достаточно что бы жить и не переживать

конечно выглядит как костыль

но не писать map в коннекте тоже как костыль выглядит

не интересно. Надо как-то смотреть не на проверти, а на селекторы. Кластеризовать проперти по тому какие селекторы они затронут и так далее.

>30 проперти иметь легко, >30 непересекающихся селекторов - сложнее.

а че они

На этом мысль меня покинула

не пересекающиеся

они могут пересекаться

в этом и суть

селекторов анлим у тебя

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

Вот пускай битики и шарят между собой.

у тебя есть пропети a,b ,c

a: 1, b: 2, c:4

селектор который будет все юзать

это 1|2|3

который ток а и б

1|2

и тд

тебе только надо определеить че юзается в селекторе

а что с @ide_ru ? подскажите плз. мне пишет что группа недоступна

а что с @ide_ru ? подскажите плз. мне пишет что группа недоступна

забанили небось

а что с @ide_ru ? подскажите плз. мне пишет что группа недоступна

у меня норм, тебя забанили скорее всего

странно :( ну лан я хотел тллько собщить что в саблайме лигатуры наконец добавили

1|2

Вот он будет 1, а первый будет 1|2, биты надо экономить. В общем стрижка только началась.

не понял

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

Потому что биты «для них». А то что там внутри переменные - не считается.

я все равно не понимаю что ты хочешь сказать

поменялось а б с

вернул 111 с калкулейт ченжед битс

а какой селектор за какими битами смотрит

не надо думаать

один может за 100 смотреть, второй за 011, третий 101, четвертый 000

чет с гугл мапс ваще все плохо на реакте

чет с гугл мапс ваще все плохо на реакте

что именно?

чет с гугл мапс ваще все плохо на реакте

недавно только вышел компонент, видел новость

чет с гугл мапс ваще все плохо на реакте

Или что там.... https://medium.com/@morgannegagne/google-maps-with-react-951c12b723ad

Люди настолько обленились, что сделать простейшую обвязку - это "плохо"

что именно?

В плане того, что есть 2 решения на данный момент, оба декларативные, оба имеют почти один и тот же функционал и стиль, и оба надо писать костыли чтобы сделать кастомные маркеры, которые можно было передвигать :^)

В плане того, что есть 2 решения на данный момент, оба декларативные, оба имеют почти один и тот же функционал и стиль, и оба надо писать костыли чтобы сделать кастомные маркеры, которые можно было передвигать :^)

юзай лефлет

Или что там.... https://medium.com/@morgannegagne/google-maps-with-react-951c12b723ad

ну я вот этот заюзал, он просто врапает гугл мапс, но с маркерами у него все плохо

но их можно хотя бы перетягивать

https://github.com/google-map-react/google-map-react

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

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

и там и там короче костылить надо

Гайз, а есть набор best practice по использованию #ramda или может даже книжка?

А то мне кажется, что у меня плохо получается его готовить ☹️

Привет! В стейте есть meta { errors: [ "ошибка", "еще ошибка" ] } ошибки добавленные в стейт должны быть показаны _один_раз в виде алерта на странице. Каким образом выполнять удаление ошибок из стейта после того как они были отображены? По логике получается, что удаление ошибки должно происходить, когда происходит любое другое действие по обновлению стейта, т.к. отдельное действие по удалению ошибки из стейта приведет к rerendering'у

Гайз, а есть набор best practice по использованию #ramda или может даже книжка?

Я на Хабре видел https://habr.com/post/348868/

errors: [ {name: "ошибка", showed: true}, {name: "еще ошибка" showed: false} ]

Я на Хабре видел https://habr.com/post/348868/

Эту серию автор забросил, емнип

Привет! В стейте есть meta { errors: [ "ошибка", "еще ошибка" ] } ошибки добавленные в стейт должны быть показаны _один_раз в виде алерта на странице. Каким образом выполнять удаление ошибок из стейта после того как они были отображены? По логике получается, что удаление ошибки должно происходить, когда происходит любое другое действие по обновлению стейта, т.к. отдельное действие по удалению ошибки из стейта приведет к rerendering'у

удаление: errors: [] и не показывать алерт, если массив пустой)

Эту серию автор забросил, емнип

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

Эту серию автор забросил, емнип

14 апреля - не так уж и давно

errors: [ {name: "ошибка", showed: true}, {name: "еще ошибка" showed: false} ]

Спасибо, но возможно я некорректно задал вопрос. Но наличие флага showed - не решает проблему, т.к. не ясно откуда устанавливать showed: true; ведь сама по себе установка этого флага - вызовет rerendering, т.к. изменит часть хранилища.

14 апреля - не так уж и давно

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