Всем привет.
Интересует, верен ли мой подход. Кто сталкивался, подскажите)
Приложение - по типу "Trello" или "kanban-подход". (доски, списки, задачи, вложения и так далее).
Текущая версия: при входе юзера, я подгружаю все данные с сервера (доски, списки и задачи, файлы и так далее), и уже на клиенте фильтрую их, в зависимости от выбора юзера. Грубо говоря, store выступает за некую базу данных на клиенте, а filter работает как "select...from...where" - если делать аналогию с серверной БД.
При небольших объемах данных все работает хорошо (пару досок, штук 15 списков и штук 50 задач). Но, как поведет себя данная схема, когда объем данных увеличится? Когда задач будет около 500 (образно представим, что юзер создал 500 задач).
И вообще, верен ли подход, когда при любом "клике" юзера (если это не связано с обновлением), я подтаскиваю нужные данные, путем фильтрации (вместо того, чтобы "дернуть" данные с сервера через API)?
davidnum95: Хотелось получить более простую схему взаимодествия. Есть еще всякого рода "панели", куда отображаются задачи с определенным статусом (важность), различные задачи-уведомления (тоже статус). Так, если мы имеем их все в одном store - то запроса делать не надо каждый раз, а необходимо только отфильтровать по нужным параметрам.
davidnum95: можно грузить только "видимые" задачи, и те, что входят в панель "важные", например. Тогда объём данных уменьшится.
И сделать ограничение на количество задач в проекте до 200 штук (мол, если юзер делает 201 задачу, то пусть делает новый проект). Думаю, что по поводу 200 задач можно не переживать)
Самое простое - сгенерировать 500-1000-whatever задач и посмотреть что будет с вашей системой.
Если говорить в общем - я думаю, что это плохое решение в большинстве случаев. Тем более, если предполагаются большие объемы данных...
чем больше объектов, тем больше overhead на map\filter\objectAssign и операции со стейтом mapState\reselect.
банальный расход памяти браузера (а если с телефона?)
большое время загрузки и парсинга вашего json.
А если уж большинство этих данных пользователь и вовсе не увидит - то зачем? На моей памяти такая модель применялась в интернет магазине, где было не много товаров, но это позволяло пользователям пользоваться ресурсом в offline режиме.
PS
Проведите тестирование (имитацию худшего сценария) и по результатам вам уже будет видно подходит это решение или нет
Благодарю за ответ.
Еще я думал, что как вариант, в начальном состоянии перекидывать только "видимую" часть (без этого уж никак), то есть все "доски", и "списки с задачами" для данной "доски".
Тогда объем данных уменьшится и будет равен объему сущностей текущей доски. При клике на другую доску - подргружаем все объекты в рамках этой текущей доски...
mr_drinkens: если у вас действительно большой объем данных для рендера (много задач на доске) - попробуйте https://github.com/bvaughn/react-virtualized . Эта штука позволяет рендерить в DOM только те элементы, которые сейчас видны на экране. Т.е. если у вас список из 1000 элементов, а видны только 10 - они и будут в DOM. При этом для пользователя это абсолютно незаметно - все выглядит как список из 1000: https://bvaughn.github.io/react-virtualized/#/comp...
По объему, пока не совсем понятно). Попробовал создать 1000 задач, 50 проектов и 2500 списков - начинает подвисать (апдейт не быстро проходит). Если же дело вообще касается drag-and-drop, то он тоже лагает). Предел - до 500 задач (всего).
Анализировал трелло и ему kanban-подобные приложения. И понял, что во всех идет подгрузка данных в рамках одной сущности.
За исключением todoist - они тупо ставят ограничение на количество задач для одного проекта (150) и кешируют все это дело).
Никита Гущин: Как вариант, и судя по различным ответам со stackoverflow, люди предлагают использовать immutable.js. Как я понимаю, это позволяет не пробегать каждый раз целиком весь массив.
То есть самое долгое по времени, в случае больших объемов, будет начальная загрузка (initiail state).
mr_drinkens: ну, лично я никогда не использовал immutable. Т.к. по сути просто можно не мутировать данные. И я не уверен, что это избавит вас от работы с массивами.
Попробуйте профайлером глянуть узкие места в вашем приложении.
Никита Гущин: нет, не использую. Судя по вопросам, люди работают и с 5000 записей в сторе, и все ок. Просто у меня одни и те же задачи используются в разных местах (панели), и было бы совсем нелогично вешать на эти панели свои запросы к АПИ. "Единый источник правды" должен сохраняться (да и удобнее это).
Можно в двух словах, для чего использовать reselect?
Спасибо
mr_drinkens: он нужен, чтобы избежать лишних перерисовок. Сейчас у вас изменились данные с store -> mapState вернул новые props -> скорее всего это привело к ререндеру. А реселект позволяет делать ререндеры только когда изменились именно нужные для компонента данные.
Никита Гущин: спасибо)
да, я в каждом компоненте прокидываю только нужные state'ы. То есть если это страница юзера, то вытаскиваю из state только сущность "user".
Больше всего "тормоза" вызывает перетаскивание (drag-and-drop) с позиции на позицию, когда я беру объект, тащу его и после прохожу по каждой задаче, дабы поменять sort-свойство (в зависимости от позиции).
На небольшом объеме все работает хорошо, если больше - тормоза (когда задач около 500). Думаю, что можно смело ограничить объем задач в одном борде до 200 штук и вывод проводить не по всем объектам в сторе, а только по задачам данного списка.
То есть если это страница юзера, то вытаскиваю из state только сущность "user".
Я имел виду: у вас на странице пользователя, помимо пользователя может быть куча другой инфы. И вот вытаскивать все ее через один connected-component "СтраницаПользователя" - черевато для производительности (лучше сделать много мелких коннектов)
На небольшом объеме все работает хорошо, если больше - тормоза.
А вы профайлером глядели что там конкретно вызывает тормоза? Может дело в рендере большого кол-ва компонентов, а не в бизнес логике как таковой?
Простой