Pull to refresh

Comments 13

Вы замеряли, как данное решение повлияло на производительность?
Каких-то специальных тестов я не делал. Не совсем ясно, что тут может понизить производительность, тем более в жизни события не запускаются один за другим так «плотно». По тому проекту, где было применено данное решение никакого ухудшения замечено не было. Все-таки – это больше реакция на какое-то внешнее воздействие, а не поток событий.

С другой стороны, я делал тест на глубину цепочки, это да. Выложил на github в examples если интересно. Прогонка на 1000 событий, где 1000ое событие взывает нулевое, образуя цикл. Главным образом делалась проверка на утечки, но и производительность с этого теста тоже видна.

Исключение не обязательно бросать, чтобы получить из него стектрейс.

Вы об этом?
https://github.com/v8/v8/wiki/Stack-Trace-API#customizing-stack-traces

Нет, об этом: new Error().stack

Ну да, но для получения подробной информации о каждом элементе стека, нужно заменить Error.prepareStackTrace на свою функцию, иначе тут будет уже конкатенированная строка.
Может я что-то делаю не так, но ваше решение не работает (будьте осторожны JS уйдет в глубокий нимб после запуска).

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

Это второй тест, который я проверял, он работает. Да, у меня по умолчанию циклы только детектятся — но не разрываются. Надо подписаться на 'onloop' и сделать throw, чтобы разорвать цикл.


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

Не думаю, что событие должно порождать событие (то есть само себя). Из этой парадигмы мы исходили, да и исходим в проектировании. Если же возникнет такая ситуация, то лучше работать с такой ситуацией, как со специальным случаем, а не наоборот. Поэтому дефалтное поведение – остановить, а возможность «вырваться» из проверки остается через «небезопасный» асинхронный вызов.

Так же ваше решение отличается еще тем, что переопределяется ряд нативных средств (setTimeout, setInterval и другие), у нас это запрещено религией), хотя по большому счету к делу это и не относится. Но в целом мне нравится. Спасибо за ваше время на эксперименты.
У меня возникает вопрос больше к использованию indexOf. Каюсь — не вникал глубоко в код, но допустим у меня вызывается событие Aa, а после него вызываю событие a — то выходит что условие indexOf отработает и будет исключение?
Если у вас есть событие «Aa» и событие «a», то это два разных события.
Sign up to leave a comment.

Articles