Что возвращает функция console log

JavaScript | console.log () с примерами

Console.log () — это функция в JavaScript, которая используется для печати любых переменных, определенных в ней ранее, или просто для печати любого сообщения, которое необходимо отобразить пользователю.

Синтаксис:

Параметры: Он принимает параметр, который может быть массивом, объектом или любым сообщением.
Возвращаемое значение: возвращает значение заданного параметра.
JavaScript-коды для демонстрации работы этой функции:

1) Передача числа в качестве аргумента: если число передано функции console.log (), то функция отобразит его.
Код № 1:

Выход:

2) Передача строки в качестве аргумента: если строка передается в функцию console.log (), то функция отобразит ее.
Код № 2:

Выход:

3) Передача char в качестве аргумента: если char передается в функцию console.log (), то функция отобразит его.
Код № 3:

Выход:

4) Передача сообщения в качестве аргумента: если сообщение передается функции console.log (), то функция отобразит данное сообщение.
Код № 4:

Выход:

5) Передача функции в качестве аргумента: если функция передается в функцию console.log (), то функция отобразит значение переданной функции ().
Код № 5:

Выход:

6) Передача числа с сообщением в качестве аргумента: если число передается функции console.log (), то функция отобразит его вместе с данным сообщением.
Код № 6:

Выход:

7) Передача строки с сообщением в качестве аргумента: если строка передается в функцию console.log (), то функция отобразит ее вместе с данным сообщением.
Код № 7:

Выход:

8) Передача символа с сообщением в качестве аргумента: если символ передается в функцию console.log (), то функция отобразит его вместе с данным сообщением.
Код № 8:

Выход:

Источник

Готовим console.log() правильно

Специально к старту нового потока курса «Frontend-разработчик» делимся с вами полезным переводом. Автор рассказывает, как использует методы логирования в производственной среде собственного проекта и в чём именно они помогают. Кроме того, нас знакомят с платформой AppSignal, созданной, чтобы напрямую уведомлять разработчика о возникающих у пользователя исключениях в приложении. Подробности под катом.

Я считаю себя инженером внутреннего программного обеспечения — и, как может подтвердить любой внутренний инженер, большая часть нашей жизни уходит на мониторинг, поиск и устранение неисправностей, а также отладку наших приложений. Фундаментальное правило разработки ПО: программное обеспечение будет давать сбои. Новых разработчиков от опытных отличает то, как они планируют эти сбои. Надежное и эффективное логирование — важная часть планирования на случай неудач и, в конечном счёте, смягчения их последствий. Как и в случае разработки бэкенда, логирование может быть полезно в разработке программного обеспечения фронтенда, но оно гораздо больше, чем просто поиск и устранение неисправностей и отладка. Эффективное фронтенд-логирование, кроме того, может сделать разработку продуктивной, быстрой и радостной.

Советы по быстрому, грязному логированию разработки с console.log()

Не используйте console.log()

Используйте имена вычисляемых свойств ES6 для идентификации объектов и чтобы не путать их с именами переменных.

Отображение уровней логирования: ERROR, WARN, INFO

При логировании списков элементов пользуйтесь console.table()

Дебажим быстро с помощью debugger

Хотите сэкономить несколько драгоценных секунд? Вместо того чтобы искать файл в консоли разработчика, в который хотите добавить точку останова, впишите в код строку debugger эта строка остановит выполнение кода. Это всё, теперь можно отлаживать и переходить к функциям, как обычно.

Тонкое профилирование с console.profile() и console.time()

Хотите профилировать поток пользователя в вашем приложении, чтобы найти горячие точки? Укажите триггер console.profile(profileName) в начале профилируемого кода и console.profileEnd(profileName) в его конце, чтобы исследовать профиль процессора в потоке.

Кроме того, можно точно измерить, сколько времени занимает выполнение потока, поместив console.time(id) в его начале и console.timeEnd(id) в его конце.

Подсчёт количества выполнений кода через console.count()

Это одна из тех функций, для которых я не нашёл особого применения, тем не менее польза от нее есть: console.count(label) помогает точно узнать, сколько раз выполняется фрагмент кода, это полезно при поиске и устранении состояния гонки и в других ситуациях.

Красивое логирование с помощью CSS

Безусловно, это моя любимая консольная функция, которую я широко использую при логировании в производственной среде (подробнее об этом — в соответствующем разделе). Ближе к сути: мы можем использовать строки форматирования, чтобы форматировать сообщения лога. Здесь %c — модификатор для кода CSS, а всё, что после него, — это сообщение.

Я выраженный визуал, мне нравится тратить какое-то время на то, чтобы информационные и отладочные логи выглядели красиво и в то же время были полезны. Я широко использую эту функцию в производственном логировании Firecode.io. И это прекрасная тема для следующего раздела.

Логирование через console.log() в производственной среде

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

Не пользуюсь console.log()

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

Внимание! Впереди фрагменты кода TypeScript. Если вы не знакомы с TypeScript, думайте о нём, как о надмножестве JavaScript с типами, на которых сделан акцент (это грубое упрощение). Иначе говоря, const str = «some string»; превращается в const str: string = «some string» — типы добавляются после имени переменной с двоеточием.

Защитите логи установкой уровня логирования на бэкенде

Я настроил Firecode.io на включение логирования на уровне отладки по умолчанию для пользователей-администраторов через переменную JavaScript, она устанавливается бэкендом. При этом предприимчивые пользователи все еще могут найти и установить соответствующие флаги в консоли разработчика, чтобы включить точный журнал. Это лучше, чем ситуация, когда каждому пользователю приложения по умолчанию представлены все логи, и лучше, чем постпроцессор, полностью удаляющий логи из приложения в производственной среде. Установка уровня логирования на бэкенде в Ruby on Rails:

Логируйте возможные ошибки и уведомляйте о них

И последнее, но не менее важное: хочется получать уведомления, когда пользователи сталкиваются с исключениями в приложении, не обязательно при этом с выводом на консоль разработчика. Это возможно. Включите вызов, передающий ваши ошибки в APM-сервис стороннего вендора (например AppSignal) в функцию ошибок вашего логгера. Пример:

AppSignal содержит интеграции для передачи ваших ошибок в службы исходящих уведомлений, таких как Slack, PagerDuty и OpsGenie, — вы даже можете подключить инструмент управления проектами, например JIRA или Trello, чтобы автоматически создавать Issues и баги для удобства вашей команды.

Итоги

Я очень надеюсь, что эти советы и истории сделают вашу фронтенд-разработку немного продуктивнее и веселее! Очевидно, что в этом посте я коснулся только поверхности боевого искусства логирования, так что, если у вас есть еще какие-то советы, которыми можно поделиться, я бы с удовольствием прочитал их в своём Twitter.

И два дополнения. Я перестраиваю Firecode.io с нуля, добавляя совершенно новый набор вопросов для собеседований по кодированию JavaScript, Java, Python и Scala.

Если вы заинтересованы в написании кода для подготовки к собеседованию, который адаптируется к вашему стилю обучения и доставляет удовольствие, зарегистрируйтесь, указав свой адрес электронной почты здесь. При запуске нового Firecode.io я предоставлю вам бесплатную трёхмесячную подписку. Я буду размещать больше материалов о создании веб-приложений промышленного масштаба (таких как Firecode.io) с нуля в качестве стороннего проекта. Если вы новичок в JavaScript и хотите понять, как объектноориентированный JavaScript и прототипное наследование работают под капотом, ознакомьтесь с моей любимой книгой по этой теме — The Principles of Object-Oriented JavaScript, и, если вам интересно узнать больше о том, почему вместо JS следует использовать TypeScript, ознакомьтесь с Effective TypeScript.

А помимо специальной литературы вам поможет промокод HABR, добавляющий 10 % к скидке на баннере.

Источник

Отладка JavaScript с помощью console.log()

Я считаю себя инженером-программистом, и, как подтвердит любой инженер-разработчик, большая часть нашей жизни тратится на мониторинг, устранение неполадок и отладку наших приложений. Фундаментальное правило разработки программного обеспечения заключается в том, что программное обеспечение всегда содержит ошибки. Новых разработчиков от опытных отличает то, как они планируют работу над ошибками. Надежное и эффективное ведение журнала — важная часть планирования сбоев и их устранения. Как и при разработке серверной части, ведение журнала может быть полезно для разработки фронтенда, но оно идет гораздо дальше, чем просто устранение неполадок и отладка. Эффективное ведение журнала внешнего интерфейса также может сделать процесс разработки продуктивным, быстрым и увлекательным.

Хотя я являюсь большим сторонником и прилежным практиком разработки через тестирование, мне нравится гибкость, богатство информации и уверенность в коде, которые браузеры предоставляют фронтенд-разработчикам, которые эффективно используют console.log(). Я подумал, что поделюсь некоторыми советами и приемами по использованию console.log, которые я изучил и включил в свой рабочий процесс с течением времени при создании Firecode.io — в надежде, что некоторые из них помогут вам сделать рабочий процесс разработки более продуктивным и увлекательным!

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

Советы по быстрому и грязному ведению журнала разработки с помощью console.log()

Не используйте console.log ().

Да все верно. Я не использую console.log(). Хорошо, хорошо, я пишу обертки, которые используют console.log() (подробнее об этом в разделе ведения журнала для производства), но если вы хотите что-то регистрировать в своем приложении, чтобы увидеть, что происходит, вместо этого используйте console.trace(). Помимо предоставления вам всего, что делает console.log(), он также выводит всю трассировку стека, чтобы вы знали, откуда именно было отправлено сообщение.

Используйте имена вычисленных свойств ES6, чтобы идентифицировать свои объекты и избежать путаницы в именах переменных.

Это просто — используйте синтаксис вычисляемых свойств ES6 и заключите объекты, которые вы хотите регистрировать, в фигурные скобки внутри console.log(), то есть используйте console.log() а не console.log(user). Это сделает вывод более аккуратно связанными с именем переменной, установленным в качестве ключа, и значением в качестве самого объекта. Это особенно полезно, когда вы спешите и хотите зарегистрировать несколько объектов одной командой console.log().

Используйте многоуровневые уровни журнала — error, warn, info

При регистрации списков элементов используйте console.table()

Эта функция не требует пояснений и является одной из моих любимых консольных функций — если вам когда-нибудь понадобится вывести список объектов, попробуйте console.table().

Быстрая отладка с помощью debugger

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

Детальное профилирование производительности с помощью console.profile() и console.time()

Хотите профилировать точный поток пользователей в своем приложении, чтобы найти горячие точки? Запустите console.profile(profileName) в начале действия и console.profileEnd(profileName) в конце, чтобы проверить профиль ЦП для потока.

В связи с этим вы можете точно измерить, сколько времени занимает поток, запустив console.time(id) в начале потока и console.timeEnd(id) в конце.

Считайте отмеченные executions с помощью console.count()

Это одна из тех функций консоли, в которых я не нашел особого применения, но она тем не менее существует. console.count(label) может помочь вам точно узнать, сколько раз выполняется фрагмент кода, что может быть полезно для поиска и устранения условий гонки и других сценариев.

Сделайте ваш лог более красивым с помощью CSS

Это, безусловно, моя любимая функция консоли, и я широко использую ее в производственном журнале (подробнее об этом в разделе производственного журналирования). Вы можете использовать отформатированные строки для форматирования сообщений журнала. %с — это заполнитель для стилей CSS, а все, что находится после, — ваше сообщение.

Вы также можете стилизовать несколько элементов, расширив строку формата, включив %s для строковых параметров.

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

Ведение журнала с помощью console.log()

Подготовка к созданию кода включает в себя ряд шагов — некоторые из них включают в себя уменьшение и сжатие вашего кода, создание дайджестов кэшируемых ресурсов и удаление console.log() из вашего приложения. Зачем? Потому что вы не хотите, чтобы вашим пользователям приходилось открывать консоль разработчика для взаимодействия с вашим приложением, что сводит на нет полезность ваших журналов и оставляет их как чистые дыры в безопасности, которыми могут воспользоваться более любознательные. В то же время, когда вы используете собственное приложение, вам, скорее всего, понадобится наиболее детализированный уровень ведения журнала, чтобы понять, как работает ваше приложение, а также найти и устранить ошибки. Если ваше приложение используется другими, вы также хотите получать уведомления, когда пользователи вашего приложения обнаруживают ошибки, чтобы вы могли отследить и исправить свой код. Вот несколько вещей, которые я делаю, чтобы максимально удовлетворить эти требования:

Не используйте console.log()

Вместо этого напишите класс-оболочку, который включает логику для условного ведения журнала на основе уровня журнала, установленного серверной частью на основе глобальной переменной. Внимание! Впереди вы увидите фрагменты кода TypeScript. Если вы не знакомы с TypeScript, думайте о нем как о надмножестве JavaScript с добавленными типами (чрезмерное упрощение), то есть const str = «some string»; становится const str: string = «некоторая строка» — типы добавляются после переменной, за которой следует точка с запятой.

В случае Firecode.io я написал свой собственный интерфейсный фреймворк, который использует RxJS, но включает знакомые концепции, такие как компоненты из других популярных фреймворков, таких как React и Vue, при добавлении дополнительных концепций, таких как движки для блоков кода с большой нагрузкой на процессор, каналы для сообщений WebSocket и клиентов для HTTP-запросов. Визуализация совместной работы всех этих частей была критически важна, поэтому я реализовал настраиваемое форматирование в классе оболочки Logger, который форматирует и визуально различает журналы из каждой части приложения.

Вместо вызова console.log(«Cache SET to», ) я вызываю Logger.debug(«Cache set to», , Framework.Cache). У класса Logger есть перечисление TypeScript, которое сопоставляет каждый компонент фреймворка используемому цвету:

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

Защитите свои журналы, установив уровень журнала на сервере

У меня Firecode.io настроен на включение регистрации уровня отладки по умолчанию для пользователей с правами администратора с переменной JavaScript, которая устанавливается бэкэндом. Хотя предприимчивые пользователи могут найти и установить эти флаги в консоли разработчика, чтобы включить детальное ведение журнала, это лучше, чем если бы все журналы были открыты для каждого пользователя вашего приложения по умолчанию, или если постпроцессор полностью удалил все журналы из вашего приложения. в производстве.

Установить во вьюхах Ruby on Rails:

И в классе Logger:

Логирование и уведомление о возможных ошибках

И последнее, но не менее важное: вам нужно получать уведомления, когда пользователи сталкиваются с ошибками, без необходимости вывода журналов в консоль разработчика. Вы можете сделать это, включив вызов для передачи ваших ошибок сторонней службе APM, такой как AppSignal, в функцию обработки ошибок вашего Logger, например так:

AppSignal включает в себя интеграции для передачи ваших ошибок в сервисы исходящих уведомлений, такие как Slack, PagerDuty и OpsGenie — вы даже можете подключить инструмент управления проектами, такой как JIRA или Trello, для автоматического создания тасков для вашей команды.

Заключение

Я очень надеюсь, что эти советы сделают вашу разработку более продуктивной и увлекательной! Я, очевидно, коснулся лишь поверхности логирования, поэтому, если у вас есть еще какие-то советы, я бы с удовольствием прочитал их в своем Twitter.

Источник