В упорной кровавой борьбе отдельные джуны-уникумы пробьются и через дефицит вакансий и через замену gpt, а если еще и доживут до момента где все ранее сформировавшиеся синьоры уйдут на пенсию, эти уникумы еще и озолотятся. Если конечно айти от тотального дефицита кадров не загнется или другой ерунды. Давайте не будем мешать естественному отбору, все равно не помешаем
Кажется вы не очень сильно представляете что такое поддержка таких монстров как авито и гос услуги, релизы новых фич, соблюдение требований к стабильности и безопастности требует длинной цепочки людей с совершенно разной компетенцией. Выпуск mvp продукта зачастую проще чем его развитие, там обычно начинается производственный ад, раздувание штата и переписывания с нуля. Ну и что касается "коробочных решений" их внедрение в реальные процессы компаний требует допиливания, интеграции с другими кусками. Я уже не говорю про то что сами коробочные решение нужно кому то пилить, писать для них плагины, интегрировать с другими коробками. Но и про что все сделано это нонсенс.
Относительно смещения при ресайзе согласен, забыл добавить это в статью. Я это решал через смещение на { x: -1 * rectSize.width / 2, x: -1 * rectSize.height / 2 } - в моей задаче нужно было рендерить в canvas параллельно
Относильное сайд эффектов с модификаций width/height не сталкивался, можно примеры? Но решение со scale имеет право на жизнь
Конечно абстрактно, мы про абстракции и говорим Во первых rx и async/await сравнивать это бред. Давай хотя бы rx и промисы сравнивать, а не их обертку. Во вторых: В чем измерять читаемость? Какие единицы измерения? Или если не понимаешь значит по определению плохо? Пример неста, как очень меинстримового решения и rxjs под капотом это как раз более объективная метрика успешности rx чем читаемость кода конкретно тобой. Там и промисы с await и rx уживаются по тому что хорошо решают разные задачи. Ты можешь реализовать (момент про тривиальность улыбнул) асинхронную, конкурентную, приоритизированную очередь использую только Promise.all, .race, .any. И все. А можешь использовать пару десятков уже готовых функций (включая аналоги этих 3х) для работы с потоками данных https://rxmarbles.com/ Я там писал выше что кнопки красить и простой json гонять можно и без rx. Если ты не сталкиваешься с задачами, которые решает rx, это не значит что он плох, я к этому веду
Чтобы дернуть один запрос с бекенда async, await достаточно, как и в 99% задач фронта. Странно говорить про технологию/методологию что она фигня, ничего в ней не понимая. Код на rx точно ни в каком виде не будет понятнее, если никогда не работал с rx. Это другая парадигму программирования (реактивное программирование) лично у меня он на фронте не прижился, на проектах был не только я, а порог входа там на голову выше чем async/await и я из мира реакта, а не ангуляра, где rx - дефолт. Но на беке активно его использовал именно для обработки потоков данных. Вообще выучил его с 0 когда мне нужно было приоритезированную очередь сделать. Могу даже код показать https://github.com/snicksnk/inst-observer/blob/develop/src/utils/ig-queque/request/requesSheduleFactory.ts Но естественно ты там ничего не поймешь. Еще rxjs всегда под капотом у nestjs Отдельная песня это тестирование марбл диаграммами, это вообще другой подход к разработке, когда ты с потоками данных работаешь, а не с императивными функциями, просто с приставкой await
Сам активно занимаюсь интерактивными визуализациями) Немного соприкасался с геймдевом для веба и там люди неиронично вызовы функций экономили и map на for заменяли и на больших объемах данных это и в правду работает. Чтобы избежать лага интерфейса можно было бы вынести расчет точек в вебворкер. Получится что основной поток приложения не будет лочится длинным циклом, сколько бы он не выполнялся. Небольшая задежка может быть, но курсор останется плавным. Еще можно подумать по поводу того чтобы упростить сложность поиска точек в среднем случае. Например создавать и обновлять при модификации отсортированный массив точек как некое подобие индекса и чем то вроде бинарного поиска икать точки для соединений.
Написал коммент до того как увидел удаление :) Меня .getItem(0) смутило, не нашел сходу как это работает с точки зрения производительности. Скорее всего ничего страшного. Ну и обращения к dom это постоянный источник узких мест. Не правильные селекторы, а тем более модификация дума могут сильно навредить производительности.
Для маленького приложения в целом можно, но мне не очень нравится идея использовать dom как хранилище состояния. Когда приложение разрастается, становится сложно отлаживать подобное. Не знаю как в случае .transform.baseVal.getItemно обычно обращения к dom дереву ухудшают производительность (тут придется делать обращение на каждом кадре). К тому же element.transform есть только в svg элементах, а значит для обычных html элементов придется реализовывать отдельную функцию. Ну а если решим использовать canvas то вообще не сработает.
В упорной кровавой борьбе отдельные джуны-уникумы пробьются и через дефицит вакансий и через замену gpt, а если еще и доживут до момента где все ранее сформировавшиеся синьоры уйдут на пенсию, эти уникумы еще и озолотятся. Если конечно айти от тотального дефицита кадров не загнется или другой ерунды. Давайте не будем мешать естественному отбору, все равно не помешаем
Кажется вы не очень сильно представляете что такое поддержка таких монстров как авито и гос услуги, релизы новых фич, соблюдение требований к стабильности и безопастности требует длинной цепочки людей с совершенно разной компетенцией. Выпуск mvp продукта зачастую проще чем его развитие, там обычно начинается производственный ад, раздувание штата и переписывания с нуля. Ну и что касается "коробочных решений" их внедрение в реальные процессы компаний требует допиливания, интеграции с другими кусками. Я уже не говорю про то что сами коробочные решение нужно кому то пилить, писать для них плагины, интегрировать с другими коробками. Но и про что все сделано это нонсенс.
Относительно смещения при ресайзе согласен, забыл добавить это в статью. Я это решал через смещение на { x: -1 * rectSize.width / 2, x: -1 * rectSize.height / 2 } - в моей задаче нужно было рендерить в canvas параллельно
Относильное сайд эффектов с модификаций width/height не сталкивался, можно примеры? Но решение со scale имеет право на жизнь
Конечно абстрактно, мы про абстракции и говорим
Во первых rx и async/await сравнивать это бред. Давай хотя бы rx и промисы сравнивать, а не их обертку.
Во вторых: В чем измерять читаемость? Какие единицы измерения? Или если не понимаешь значит по определению плохо?
Пример неста, как очень меинстримового решения и rxjs под капотом это как раз более объективная метрика успешности rx чем читаемость кода конкретно тобой.
Там и промисы с await и rx уживаются по тому что хорошо решают разные задачи.
Ты можешь реализовать (момент про тривиальность улыбнул) асинхронную, конкурентную, приоритизированную очередь использую только Promise.all, .race, .any. И все. А можешь использовать пару десятков уже готовых функций (включая аналоги этих 3х) для работы с потоками данных https://rxmarbles.com/
Я там писал выше что кнопки красить и простой json гонять можно и без rx. Если ты не сталкиваешься с задачами, которые решает rx, это не значит что он плох, я к этому веду
Чтобы дернуть один запрос с бекенда async, await достаточно, как и в 99% задач фронта. Странно говорить про технологию/методологию что она фигня, ничего в ней не понимая. Код на rx точно ни в каком виде не будет понятнее, если никогда не работал с rx.
Это другая парадигму программирования (реактивное программирование) лично у меня он на фронте не прижился, на проектах был не только я, а порог входа там на голову выше чем async/await и я из мира реакта, а не ангуляра, где rx - дефолт.
Но на беке активно его использовал именно для обработки потоков данных. Вообще выучил его с 0 когда мне нужно было приоритезированную очередь сделать. Могу даже код показать
https://github.com/snicksnk/inst-observer/blob/develop/src/utils/ig-queque/request/requesSheduleFactory.ts
Но естественно ты там ничего не поймешь.
Еще rxjs всегда под капотом у nestjs
Отдельная песня это тестирование марбл диаграммами, это вообще другой подход к разработке, когда ты с потоками данных работаешь, а не с императивными функциями, просто с приставкой await
Сам активно занимаюсь интерактивными визуализациями) Немного соприкасался с геймдевом для веба и там люди неиронично вызовы функций экономили и map на for заменяли и на больших объемах данных это и в правду работает.
Чтобы избежать лага интерфейса можно было бы вынести расчет точек в вебворкер. Получится что основной поток приложения не будет лочится длинным циклом, сколько бы он не выполнялся. Небольшая задежка может быть, но курсор останется плавным.
Еще можно подумать по поводу того чтобы упростить сложность поиска точек в среднем случае. Например создавать и обновлять при модификации отсортированный массив точек как некое подобие индекса и чем то вроде бинарного поиска икать точки для соединений.
Написал коммент до того как увидел удаление :) Меня .getItem(0) смутило, не нашел сходу как это работает с точки зрения производительности. Скорее всего ничего страшного.
Ну и обращения к dom это постоянный источник узких мест. Не правильные селекторы, а тем более модификация дума могут сильно навредить производительности.
Для маленького приложения в целом можно, но мне не очень нравится идея использовать dom как хранилище состояния. Когда приложение разрастается, становится сложно отлаживать подобное.
Не знаю как в случае
.transform.baseVal.getItemно обычно обращения к dom дереву ухудшают производительность (тут придется делать обращение на каждом кадре).К тому же element.transform есть только в svg элементах, а значит для обычных html элементов придется реализовывать отдельную функцию. Ну а если решим использовать canvas то вообще не сработает.