Comments 13
Вы замеряли, как данное решение повлияло на производительность?
+3
Каких-то специальных тестов я не делал. Не совсем ясно, что тут может понизить производительность, тем более в жизни события не запускаются один за другим так «плотно». По тому проекту, где было применено данное решение никакого ухудшения замечено не было. Все-таки – это больше реакция на какое-то внешнее воздействие, а не поток событий.
С другой стороны, я делал тест на глубину цепочки, это да. Выложил на github в examples если интересно. Прогонка на 1000 событий, где 1000ое событие взывает нулевое, образуя цикл. Главным образом делалась проверка на утечки, но и производительность с этого теста тоже видна.
С другой стороны, я делал тест на глубину цепочки, это да. Выложил на github в examples если интересно. Прогонка на 1000 событий, где 1000ое событие взывает нулевое, образуя цикл. Главным образом делалась проверка на утечки, но и производительность с этого теста тоже видна.
0
Исключение не обязательно бросать, чтобы получить из него стектрейс.
+4
Вы об этом?
https://github.com/v8/v8/wiki/Stack-Trace-API#customizing-stack-traces
https://github.com/v8/v8/wiki/Stack-Trace-API#customizing-stack-traces
0
Спасибо, сработали суеверия. Вы совершенно правы. Подправил, обновил.
0
У меня получилось проще: https://github.com/mayorovp/tiny-safeevents/blob/master/safeevents.js
Вместо ловли стека через исключение я в явном виде отслеживаю этот стек во внутреннем массиве.
+6
Может я что-то делаю не так, но ваше решение не работает (будьте осторожны JS уйдет в глубокий нимб после запуска).
У меня было решение без именных функций сродни вашему, но там возникает проблема иного рода, а именно нужно чуть более усердно думать об очистке за собой. Поэтому решение с именными функциями мне показалось наиболее оптимальным, так после себя ничего не оставляет. С этим примером можно в этом убедиться.
У меня было решение без именных функций сродни вашему, но там возникает проблема иного рода, а именно нужно чуть более усердно думать об очистке за собой. Поэтому решение с именными функциями мне показалось наиболее оптимальным, так после себя ничего не оставляет. С этим примером можно в этом убедиться.
0
Это второй тест, который я проверял, он работает. Да, у меня по умолчанию циклы только детектятся — но не разрываются. Надо подписаться на 'onloop'
и сделать throw
, чтобы разорвать цикл.
Связано это с тем, что не вполне понятно как один обработчик в подобной системе сможет отменить другой — поэтому я не стал добавлять заведомо деструктивных действий в обработчик по умолчанию.
0
Не думаю, что событие должно порождать событие (то есть само себя). Из этой парадигмы мы исходили, да и исходим в проектировании. Если же возникнет такая ситуация, то лучше работать с такой ситуацией, как со специальным случаем, а не наоборот. Поэтому дефалтное поведение – остановить, а возможность «вырваться» из проверки остается через «небезопасный» асинхронный вызов.
Так же ваше решение отличается еще тем, что переопределяется ряд нативных средств (setTimeout, setInterval и другие), у нас это запрещено религией), хотя по большому счету к делу это и не относится. Но в целом мне нравится. Спасибо за ваше время на эксперименты.
Так же ваше решение отличается еще тем, что переопределяется ряд нативных средств (setTimeout, setInterval и другие), у нас это запрещено религией), хотя по большому счету к делу это и не относится. Но в целом мне нравится. Спасибо за ваше время на эксперименты.
0
У меня возникает вопрос больше к использованию indexOf. Каюсь — не вникал глубоко в код, но допустим у меня вызывается событие Aa, а после него вызываю событие a — то выходит что условие indexOf отработает и будет исключение?
0
Sign up to leave a comment.
42 строки кода для выхода из лимба