Получение индекса в массиве тоже может занять куда более O(n), если например по каждому элементу делается сложная проверка. Так что нет никакого смысла в оценку операции вставки добавлять ещё и поиск.
GlazOtca, здесь есть всего 3 вызова хука - два useState(..) и один useEffect.(..) Они все безусловно вызываются на верхнем уровне компонента App.
Поинт про внешнюю функцию не понял.
Да, впечатляет. Интересно, почему буфер не загружается синхронно. Хотя вот только сейчас подумал: тебе и не нужен буфер, а нужна именно строка, чтобы в ней сделать поправки! Так что да, TextEncoder в помощь, всё правильно.
Вообще, удивительно, что в браузере до сих пор нет нормального встроенного средства кодирования бинарника в base64, как в node.js. "Строковый" параметр для btoa - какое-то средневековье.
Сергей Соколов, ну тогда, по идее, fetch должен режектиться сам.
вызовы SDK, наверно, не умеют принимать abortController? тогда можно обернуть последний в промис (который будет режектиться по аборту), и этот промис присовокуплять, например, через Promise.race к вызовам SDK, либо просто написать для этих вызовов универсальную обертку с конструктором промиса, в котором отслеживать abortController, и работать с SDK уже через эту обертку.
Тогда не придется везде втыкать проверку - аборт в abortController вызовет reject в любой текущей асинхронной операции, и прервется вся цепочка.
Евгений Журов, для findIndex достаточно проверить на равенство. Потому что он тупо обходит массив и проверяет каждый элемент. А для бинарного поиска не обойтись без сравнения "меньше". В этом ключевая разница.
Полагаю, удобнее будет первый вариант, где колбэк возвращает -1, 0 или 1 (точнее, вместо -1/1 могут быть любые значения меньше/больше нуля). Такой колбэк, например, использует стандартная js функция сортировки массива, это устоявшийся привычный кейс.
да нет, не любое. Изображения с другого сервера нарисуются на канве, но toBlob после этого уже не сработает. Там тот же принцип - если нельзя скачать аяксом, то и нельзя забрать с канвы.
Anonymous Penguin, нет, реверсить не придется, я ведь предлагаю сделать цикл в обратном направлении. unshift в цикле нежелателен - приводит к О(N^2) на ровном месте, это может сказаться на скорости, если итераций много
А что за либа? Почти наверняка она это делает через canvas, у которого кроме toDataUrl есть ещё toBlob. Я к тому, что стоит присмотреться к документации либы, возможно там есть сохранение в блоб вместо base64.
Владимир Коротенко, эти тонкости тоже могут сильно зависеть от фигур. Если будет какой-то переиспользуемый код, то его лучше вынести в утилсы. Ну или как крайний вариант, для каких-то фигур сделать общие промежуточные подклассы.
Понадобятся подклассы для рисования каждого типа фигур (разумеется, если автору вопроса надо напроектировать православное ООП, а не скатиться в switch/case).
Причем экземпляр класса-рисовальщика по хорошему должен получить свою конкретную фигуру как параметр в конструктор, потому как нельзя передавать ему в render эту фигуру как ссылку на базовый NewShape.
На самом верху будет массив или словарь с фабриками, которые создают как фигуру, так и рисовальщика. Причем, если рисовальщик создается не вместе с фигурой, то не обойтись без ручного приведения NewShape к конкретному типу...