Привет всем, был у кого опыт работы с несколькими redux

сторами и redux-thunk?

Ошибаешься) есть возможность

Ок. Значит, в стайл гайде писали о том, что не надо так)0)

Да, так и есть, но а случае необходимости( огромные листа элементов)- можно

Вообще уже если решишь использовать реселект, то устанавливай redux toolkit

В нем и проблема. CD запускается для 75000 элементов, что приводит к очень сильному лагу. А вызывается он, потому что меняется стор)

Тебе нужно сразу все 75000 элементов вывести?

Да. Это карта

В каком смысле?

В прямом) это Стадион на 75000 мест

И он прям весь отображается?

Это надо канвасом

Он тоже не вывезет)

так вроде же делят на сектора/части света и тд сразу все зачем то

Если не вывезет, то уже ничто не поможет

Специфика :)

+ переписать никто не даст + можно это победить разделением стора

Проблема не в сторе, проблема в доме

Интересная задача. Только пользователю, зачем столько элементов на экране? Я если такое увижу, сразу приложение закрою :)

Тогда думаю, что лучше в состояние компонента вынести.

Покупка билетов на матч)

Подробнее можно?

75000 дом элементов одновременно отрендерендерить - это всегда будет тормозить

а нельзя сделать показ только сектора какого то , а весь стадион отобразить на миникарте (канвасе)

Да, но они не перендериваются) Проблема в том, что постройка virtual dom + проверка селекторов занимает очень много времени

Можно, но заказчики так хотят

просто если сиденья будут хотяб по 4 пикселя , это займет весь экран , пользователю неудобно будет работать с такими маленькими объектами

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

ну они как минимум первоначально долго будут рендериться. А для максимального ускорения апдейтов нужно передавать стейт строго через пропсы с использованием memo

Главное чтобы все понимали, что на мобиле оно может вообще не открыться)

смотри , 273 х 273 пикселя это 75 000 мест по одному! пикселю , какого размера должно быть одно место ?

Да я все это знаю, абсолютно. Я в исходника все перерыл дальше. Очень глубоко его изучал и знаю. Ререндеров лишних не бывает ни в какой из случаев. Performance leak происходит в useSelector( все кешируется), который вызывается при смене стора. Для проверок изменений

а сколько времени ушло всю эту красоту в свгшке сделать?

жесть)

Ты ссылку кидай, а не картинку

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

Я это видел год назад наверное. Чуть кривее. Это ты его делал или подобрал?

и так можно его использовать на любом устройстве( дизайнеры не зря существуют на планете)

млжет быть. работать я не переставал тут

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

а я причём тут ? 😁

просто начал на твоем писать и понесло)

75000 мест и тут redux 🌚 (лаги) @maximkoylo @risenforces

Так и есть. Поэтому и разделяю. Разделить на 2-3 стора проще, чем подключать другие стейт манагеры

я ему пытался донести что информацию никакую не разместить на таких мелких местах и типа нет смысла юзать 75 000 дом элементов

В случае свг карты- есть :)

я бы всё равно сделал на канвасе , слишком это просто для svg. + канвас и мобилки потянут

Да они и свг тянут прекрасно с хорошей оптимизацией. Только первый рендер дольше и все) естественно мобилкам хуже, когда это все у них происходит( я имею ввиду подобные стадионы), но работать все и так будет. Проблема в том, что есть 2 пути: либо другой стейт манагер, либо разделять стор редакса( первый- дольше). Тут был человек, который занимался частичным переходом и потом полный на другой стейт манагер. Интересно было бы послушать Степы и взаимосвязь между двумя стейтами

Идиотизм

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

@risenforces прошу 🧎

Попробуем, если быстро не получится разделить Редакс. Спасибо

разделить редакс на несколько сторов?

Что только не сделаешь вместо нормального стм)

Ну скажи, скажи уже, что нужно вместо релаксацию. Я знаю - ты хочешь

он говорит про НЕ редакс, а не про то что ты подумал

Угу. https://react-redux.js.org/using-react-redux/accessing-store#providing-custom-context Главная проблема в redux-thunk сча

потому и не советую, это ужасно

Согласен. Переводить на другой стм долго, поэтому и ищутся решения проще и быстрее, так как время ограничено

подключить точечно мобх 2 минуты

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

Первый вопрос для чего тебе в редаксе сейвить 75000 мест? Нельзя в локальный стейт занести? Второй вопрос рендер первый не лагает на 75к мест? Есть какое то кэширование, оптимизация рендера при зуминге только рисование мест на экране?

Угу, апдейтится только стили смещения свг. Кэшируется все большие селекторы( Аля данные сита). Первый рендер и вправду занимает больше необходимого, но это лишь 50% элементов, второй половиной пользователей может пользоваться свободно.( однако это не оптимизировать из-за легаси проекта и просчетов. Никто менять не будет) В стейт локальный не получится занести, так как карта может благополучно появлятся, исчезать. Данные для отрисовки появляются после расчета файлов, которые пришли с сервера( про их расположение и доступность, не считая разные вещи, которые провайдятсч там же). Данные о расположениях не рассчитываются динамически. + данные о ситах могут использоваться в разных частях проекта( для получения некоторой инфы о них). Насчёт оптимизации стора- оптимизировано максимально сильно. Лишних рендеров не имеется, лишние данные и компоненты не меняются. Обновляется, при движении например, только одна компонента, отвечающая за смещение и зум) и тд. Насчёт выбора и тд- все это хранится отдельно и никак не аффектает сами ситы. После изучения всех моментов перформанс табы( хрома) + изучение профайлера и стейт состояния с проверкой селекторов и тд, понял и нашёл, что bottleneck в том, что это один большой стейт, после изменения которого идёт пересчёт селекторов для понимания, какие компоненты должны быть проверены и срендерены., то есть самая большая активная в useSelector внутри тех же ситов, при построении fiber нож

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

Может быть на сервере есть возможность перед отдачей на клиент проверять какие места уже заняты и отдавать только свободные места на клиент, и потом уже на клиенте в реальном времени обновлять места точечно, в зависимости от того что прилетает на сервер. И еще, зачем пользователю видеть места которые уже заняты, наверняка он хочет видеть свободные места? Но если по результатам тестирования, была выявлена проблема в едином сторе Редакса, то тут уже всё очевидно.

Есть такая возможность даже на уровне первой загрузке выявлять, но по требованиям надо показывать все места :(

Раздели стейт на визуальный (зум, смещение, открытие модалок и тултипов, etc.), который тебе вообще не нужен и бизнесовый (фильтры, формы, etc.). Первый тупо в визуальных компонентах (useState/контекст/че угодно) без доступа извне, второй в редакс. Данные нормализуй и трансформируй в другие структуры, чтобы не перелопачивать массивы с тысячами объектов.