Comments 7
Преждевременная оптимизация — зло. Но её путают часто со следованием архитектуре (как бы подразумеваемой, неявно, но которой зачастую попросту нет в момент принятия таких решений).
Решать, какие функции и методы должны быть синхронными, какие асинхронными, какие будут возвращаться ошибки и как обрабатываться, какие типы модулей могут использовать какие модули, каким модулям можно ходить в интернет, а каким в БД и всё такое прочее нужно на этапе проектирования архитектуры, а не гадая по одной конкретной функции, кто её в будущем и как решит использовать.
Решать, какие функции и методы должны быть синхронными, какие асинхронными, какие будут возвращаться ошибки и как обрабатываться, какие типы модулей могут использовать какие модули, каким модулям можно ходить в интернет, а каким в БД и всё такое прочее нужно на этапе проектирования архитектуры, а не гадая по одной конкретной функции, кто её в будущем и как решит использовать.
М… Даже странно как-то видеть такую статью. Промис в принципе не должен передаваться как аргумент, если это не функция для работы с промисами, такая как Promise.all или Promise.race. Так же как и скрываться ошибка из промиса не должна внутри библиотечной функции.
Полезная статья
Никогда не видел, чтобы кто-то так писал. Возвращать промисс это да, но передавать параметром как-то не принято. Может быть мне везло.
Ну иногда видел похожие вещи в коде. Зачастую такой код любят писать c promise.All Читать может и красиво а вот с реверс инженирингом начинается батхерт. Если помнить одно простое правило что промис чейнится можно спокойно писать обычные функции и вызывать цепочку. И вот такой огород не нужен.
Единственное когда я таким вот сам лично грешу это когда пишу стабы для апи которого ещё нет. Так сразу видно другим людям что тут когда-то будет апи вызов.
Sign up to leave a comment.
Не нужно оборачивать все в Promise