два варианта:
1 - Принимать функция для логгирования как зависимость, потом частично применять её. Звучит не очень, на каждую что ли вешать дополнительный параметр?
2 - Декоратор для Result, если следовать Railway, то можно сделать обертку над Result, и при каждом вызове Ok|Fail автоматически делать лог. В мыслях вижу этот подход идеальным.
3 - Вставлять логгирование в pipe'ы вызова обычных функций
лучше просто вызывать логгер
напиши еще экспрешн билдер кастомный ))
Функция даст слишком мало возможностей. У инстанса логгера их гораздо больше.
Я иногда, когда аргументов слишком много становится, ввожу некий контекст, в котором лежит логгер и другие зависимости функции. И вот его уже принимаю в аргументы. Уж не знаю, ФП там или не ФП, но просто делаю так.
Обязательно посмотрю, спасибо
Тоже собираю все в один рекорд и называют его env таская везде
Один логер на приложение - не очень, нельзя будет гранулировано управлять ими через конфиги
А кто сказал что он там один? 1. Какой в контексте передашь — такой и будет. 2. Сервис может сам создать derived logger, тут уж как организуешь.
А, я думал этот рекорд ты таскаешь как синглтон
дак через конфиги можно управлять подсистемами/эвентами логов, один логер этому не мешает (вроде)
Обсуждают сегодня