Да, техническое образование у меня есть, в котором присутствовал и ассемблер и C++. И я бы с удовольствием взглянул на ваш алгоритм, возможно действительно можно улучшить, так как я вполне осознаю, что это на данный момент временное решение и по хорошему улучшить алгоритм отрисовки
Способ решения выбран был просто - необходимо сделать быстрее в короткий срок без долгих обдумываний и переделок. Плюс это новый метод, который хотелось опробовать и который неплохо справляется в данной ситуации
Проблема не в сложности алгоритмов, а в количестве прилетаемых данных. Сложность O(n^2), так как идет маппинг по категориям (их максимум 5) и дальше внутри категорий раскидываются данные по компонентам фильтров в зависимости от вида фильтра. При этом данные уже преобразованные, поэтому дополнительных преобразований не производится, кроме как просто распределения данных по компонентам.
И как я и писал проблема возникает только при большой выдаче, так как фильтров может прилететь очень много.
Можно сказать, что это бред, но как я и сказал - это внутренний продукт и достаточно специфичный и из-за такой специфики возникают такие сложности, поэтому прошу не переходить на оскорбления
В данном случае пришлось поставить задержку процессора в производительности, так как на мощных компах (которые есть не у всех пользователей) разницы практически нет.
Какой итог?
При применении setTimeout(getFilterData,0) расчет начинается после прохождения цикла в EventLoop и возникает такая ситуация: - Просчитались открытые категории - Сайдбар открылся - Нажать никуда не получается, так как начал отрабатывать колбек из таймаута и начались расчеты закрытых категорий, а пользователь в это время теряет интерактивность, так как еще не все успело подгрузиться и отрисоваться
При применении requestIdleCallback такой проблемы с потерей интерактивности интерфейса замечено не было (пробовал несколько раз)
Да, тоже его видел, там действительно на setTimeout и это скорее на данный момент единственное похожее решение (по крайней мере я других не вижу пока что). Когда нибудь и они поддержат этот метод:)
На самом деле еще зависит от мощностей устройства на котором воспроизводится. У меня на старом маломощном ноуте бывало подвисало уже при 10-15 (ноут уже совсем убит), поэтому мне кажется сказать точную цифру в данном случае нельзя без описания дополнительных условий
Было бы удобнее, если бы столбцы в таблицах были бы хоть как-то подписаны. Сложно сразу сориентироваться. Читал с телефона, сначала показалось, как бессвязный текст в столбцах
Из развивающихся библиотек я бы еще Consta наверное упомянул, сейчас с ней работаю, вполне не плохо. Есть конечно свои недостатки, но так как разработка ведется у них постоянно, то можно и в телеге в чатике разработчиков просить баги поправить
К сожалению, не я решаю пул технологий и мне сказали пока Vite не трогать, оставить на будущие эксперименты, когда будет больше времени) Так бы сам попробовать его хотел на каком-нибудь коммерческом проекте
Да, так и сделал по итогу ж) Единственное, что вокруг куча разных сборок, да и сам их пишешь не каждый день, поэтому хотелось бы понимать, нормально ли вообще делаешь или фигню катаешь какую-то
Рад, что моя статья вам понравилась, спасибо за добрые слова)
Насчет деструктуризации при использовании всего объекта. Да, вы в какой-то мере правы. Но я думаю, что в проекте лучше все держать в одних принципах и одном синтаксисе. Сейчас деструктуризация не мешает, а завтра надо будет отрефакторить или изменить логику и уже используется не весь объект и все равно менять использование.
Спасибо за наводку) Интересный кейс, сам с таким не сталкивался. В будущем постараюсь разобрать его и, в случае чего, написать статью, так как действительно звучит как проблема, хоть и редкая, но необходимая к освещению
Безумно интересная статья. Если честно, даже не подозревал, что можно таким способом реализовывать описанные вещи, так как мало с таким сталкивался. Спасибо вам)
Хотел бы спросить у автора по поводу моральной составляющей разработчиков. Все описанное как-будто бы делает работу разработчиков очень динамичный и постоянно напряженной, так как надо каждый час за чем-то следить и быстро править. Как с этим справляется команда? Или есть условно дежурные, которые периодически меняются и команда является не сильно маленькой, чтобы не бросать груз ответственности на пару людей?
Хитро, хитро)
Хорошая выжимка видео, помогает, если не хочется смотреть весь видос и особенно в качестве конспекта)
Спасибо, возьму на заметку. Как будет время покопаюсь)
Да, техническое образование у меня есть, в котором присутствовал и ассемблер и C++. И я бы с удовольствием взглянул на ваш алгоритм, возможно действительно можно улучшить, так как я вполне осознаю, что это на данный момент временное решение и по хорошему улучшить алгоритм отрисовки
Способ решения выбран был просто - необходимо сделать быстрее в короткий срок без долгих обдумываний и переделок. Плюс это новый метод, который хотелось опробовать и который неплохо справляется в данной ситуации
Проблема не в сложности алгоритмов, а в количестве прилетаемых данных. Сложность O(n^2), так как идет маппинг по категориям (их максимум 5) и дальше внутри категорий раскидываются данные по компонентам фильтров в зависимости от вида фильтра. При этом данные уже преобразованные, поэтому дополнительных преобразований не производится, кроме как просто распределения данных по компонентам.
И как я и писал проблема возникает только при большой выдаче, так как фильтров может прилететь очень много.
Можно сказать, что это бред, но как я и сказал - это внутренний продукт и достаточно специфичный и из-за такой специфики возникают такие сложности, поэтому прошу не переходить на оскорбления
В данном случае пришлось поставить задержку процессора в производительности, так как на мощных компах (которые есть не у всех пользователей) разницы практически нет.
Какой итог?
При применении setTimeout(getFilterData,0) расчет начинается после прохождения цикла в EventLoop и возникает такая ситуация:
- Просчитались открытые категории
- Сайдбар открылся
- Нажать никуда не получается, так как начал отрабатывать колбек из таймаута и начались расчеты закрытых категорий, а пользователь в это время теряет интерактивность, так как еще не все успело подгрузиться и отрисоваться
При применении requestIdleCallback такой проблемы с потерей интерактивности интерфейса замечено не было (пробовал несколько раз)
Да, тоже его видел, там действительно на setTimeout и это скорее на данный момент единственное похожее решение (по крайней мере я других не вижу пока что). Когда нибудь и они поддержат этот метод:)
На самом деле еще зависит от мощностей устройства на котором воспроизводится. У меня на старом маломощном ноуте бывало подвисало уже при 10-15 (ноут уже совсем убит), поэтому мне кажется сказать точную цифру в данном случае нельзя без описания дополнительных условий
Понял, спасибо за разъяснение)
Статья очень информативная, спасибо! Я хотел задать вопрос по поводу Modern. Что в данном случае принимается за нее?
Было бы удобнее, если бы столбцы в таблицах были бы хоть как-то подписаны. Сложно сразу сориентироваться. Читал с телефона, сначала показалось, как бессвязный текст в столбцах
Из развивающихся библиотек я бы еще Consta наверное упомянул, сейчас с ней работаю, вполне не плохо. Есть конечно свои недостатки, но так как разработка ведется у них постоянно, то можно и в телеге в чатике разработчиков просить баги поправить
К сожалению, не я решаю пул технологий и мне сказали пока Vite не трогать, оставить на будущие эксперименты, когда будет больше времени) Так бы сам попробовать его хотел на каком-нибудь коммерческом проекте
Да, так и сделал по итогу ж) Единственное, что вокруг куча разных сборок, да и сам их пишешь не каждый день, поэтому хотелось бы понимать, нормально ли вообще делаешь или фигню катаешь какую-то
Действительно большинство скорее всего использует уже свои настройки и сборщики. Но я лично точно встречал пару проектов в продавшене на CRA
Да, CRA в принципе холиварная вещь. Посмотрим, что по итогу они из него сделают
Рад, что моя статья вам понравилась, спасибо за добрые слова)
Насчет деструктуризации при использовании всего объекта. Да, вы в какой-то мере правы. Но я думаю, что в проекте лучше все держать в одних принципах и одном синтаксисе. Сейчас деструктуризация не мешает, а завтра надо будет отрефакторить или изменить логику и уже используется не весь объект и все равно менять использование.
Спасибо за наводку) Интересный кейс, сам с таким не сталкивался. В будущем постараюсь разобрать его и, в случае чего, написать статью, так как действительно звучит как проблема, хоть и редкая, но необходимая к освещению
Безумно интересная статья. Если честно, даже не подозревал, что можно таким способом реализовывать описанные вещи, так как мало с таким сталкивался. Спасибо вам)
Очень интересная и познавательная статья!
Хотел бы спросить у автора по поводу моральной составляющей разработчиков. Все описанное как-будто бы делает работу разработчиков очень динамичный и постоянно напряженной, так как надо каждый час за чем-то следить и быстро править. Как с этим справляется команда? Или есть условно дежурные, которые периодически меняются и команда является не сильно маленькой, чтобы не бросать груз ответственности на пару людей?