Кстати, если возникает желание протестировать приватный метод, стоит еще раз критически взглянуть на архитектуру.
Возможно кто-то в спешке нагородил процедурщину. А еще может быть, что класс пытается брать на себя больше одной ответственности (поэтому дополнительную фунциональность, которая не является ответственностью класса, завернули в приватный метод). В этом случае стоит попытаться вынести функциональность приватного метода в отдельный класс, где она будет основной, а следовательно публичной, и тестировать по обычной методике.
Сам промис подразумевает, что действие стартует непосредственно в момент обещания. Они не ленивые. Создание промиса сродни запуску ракеты, которая должна доставить спутник на орбиту — когда она отрывается от земли уже поздно передумывать. С промисами в этом плане есть только два варианта: либо не обещать совсем, либо пытаться игнорировать результат как будто ни чего не было.
Получается, что fetch должен выставлять наружу не промис, а что-то еще, что позволит достичь нужного эффекта. Вариант с Observable рассматривали выше. Можно еще попытаться приспособить yield. В принципе это те же яйца, наизнанку. С помощью генератора можно мониторить статус, а при необходимости забросить внутрь исключение, которое приведет к остановке.
С одной стороны дикая инфляция технологий доставляет неудобства: сложно ощущать себя профессионалом и продаваться наравне с профи в других областях. С другой, обеспечивает работодателю стабильный поток заказов с поддержки и дешманский труд. Особенно когда речь идет о крупных проектах, а не лендинге. Это IT, детка. Бизнес простых чисел. Ты либо единица, либо ноль. :)
пока меня не задели за живое. tc-39/proposal-cancelable-promises — мы все очень ждем в стандарте языка, который был написан человеком из Google, который шёл-шёл-шёл, дошёл до Stage-1 (или Stage-2, я не помню), и в один прекрасный момент был отозван
Это говорит о том, что человеки разумные могут не только совершать ошибки, но и признавать их, даже когда все зашло очень далеко.
Cancelable Promises изначально появились из-за попытки решить проблему не на том уровне абстракции. Промис по смыслу является значением. Как должна выглядеть отмена значения, чисто с позиции логики? Проблемы в логике не решаются кодингом и костылями. Bluebird это уже два раза доказал на практике, сначала сделав одну реализацию C-P с кучей «особенностей», а потом еще раз переписав с нуля уже с другой кучей.
Как вариант, нормальный способ отмены чего-либо предложен в Observable, которые представляют собой последовательности. Promise и Observable это две штуки, которые прекрасно решают свои задачи и уживаются вместе.
Взять например популярный патерн «Command», с единственным «execute()» в интерфейсе, и кучей indirect inputs/outputs внутри, на которых код может валиться.
Выше вы пишите, что проверки сертификатов осуществляются локально по базе отпечактов. Станет-ли браузер выдавать предупреждения, если на сайте (легитимно, а не злоумышленники) поменяют сертификат, например из-за окончания срока предыдущего?
На стадии эксплуатации это «элементарно» может стоить несколько недель. Ведь в таком случае баг еще надо найти, описать, засабмитать, приоритезировать, разобраться, починить, проревьювать, протестить, задеплоить, зарелизить, обновить.
Если сертификат на сайте поменяется, как будет реагировать браузер? Есть-ли отдельный механизм для обновления отпечатков, или только вместе с новой версией браузера?
По моему опыту, наличие штатного репозитория для артефактов сборки, супервизора процессов, а так же изоляции по файловой системе и сетевым портам снимает здоровый пласт с инфраструктуры и в разы упрощает деплой.
Мне правда интересно, как это воспроизвести. Если речь об одной машинке, то сетевые интерфейсы на линукс машинке это обычный бридж и несколько правил в iptables. При желании можно использовать host network, тогда вообще ни каких отличий не будет.
Почитаем на пальцах? SSH не нужен. Образ monogdb и конфиг один вместо трех — разницу задаем через переменные окружения и volume. Трюки с симлинками и пользователями убираем — версионность образов «изкаропки». pm2 так же исключается — у докера свой супервизор. Итого 2/3 статьи можно просто было не писать. Сценарии в виде Dockerfile, docker-compose вы бы могли выложить на github и дать возможность читателям на 100% воспроизвести решение, с точностью до приложения meteor.
Возможно кто-то в спешке нагородил процедурщину. А еще может быть, что класс пытается брать на себя больше одной ответственности (поэтому дополнительную фунциональность, которая не является ответственностью класса, завернули в приватный метод). В этом случае стоит попытаться вынести функциональность приватного метода в отдельный класс, где она будет основной, а следовательно публичной, и тестировать по обычной методике.
Получается, что fetch должен выставлять наружу не промис, а что-то еще, что позволит достичь нужного эффекта. Вариант с Observable рассматривали выше. Можно еще попытаться приспособить yield. В принципе это те же яйца, наизнанку. С помощью генератора можно мониторить статус, а при необходимости забросить внутрь исключение, которое приведет к остановке.
https://github.com/tc39/proposal-observable
Cancelable Promises изначально появились из-за попытки решить проблему не на том уровне абстракции. Промис по смыслу является значением. Как должна выглядеть отмена значения, чисто с позиции логики? Проблемы в логике не решаются кодингом и костылями. Bluebird это уже два раза доказал на практике, сначала сделав одну реализацию C-P с кучей «особенностей», а потом еще раз переписав с нуля уже с другой кучей.
Как вариант, нормальный способ отмены чего-либо предложен в Observable, которые представляют собой последовательности. Promise и Observable это две штуки, которые прекрасно решают свои задачи и уживаются вместе.
Как вы считаете, из-за чего происходит эта просадка?