Comments 10
Консоль, консоли рознь, заголовок слишком абстрактный
несколько лет назад видел что в chrome dev tool есть свой селектор css как jquery не напомните ? там как то $_.()
Щас как расскажу вам тайну!
Короче в Node.js есть еще приватный консоль-лог. Это process._rawDebug. Разница с console.log в том, что приватная версия не триггерит никаких асинхронных апишек. Вот например можно разницу увидеть в использовании async_hooks:
import { createHook } from 'async_hooks'
createHook({
init: () => {
console.log('oops') // <- вот тут будет max call stack size exceeded
process._rawDebug('oops') // <- тут нет
}
}).enable()
Прикольно узнать такие фишки в консоли. Только одного не понял: в чём разница console.log и console.info если с визуальной точки зрения, они одинаковые?
Работа над любым материалом подобного характера, должна начинаться с чтения первоисточника.
Для любого программиста, первоисточником является официальная спецификация.
Не mdn, не материал другого человека, а официальная спецификация.
Посмотрим на примере этого материала, чтобы с ним стало если бы его автор, так и поступил. То есть начал бы с чтения спецификации.
Мы бы узнали, что
Мы собираемся говорить не о командах консоли. А о имплементации определенного API, к которому, зачастую, можно иметь доступ в консоли некоторых host сред. Но это не сама консоль.
console (именно так с маленьнкой буквы) это API, которое прямого отношения к JavaScript не имеет. И целиком зависит от host implemetation. То есть большая часть ее машинерии лежит на совести host системы. host система - это, в рамках спецификации JavaScript, среда для работы самого JavaScript. Например Браузер, Node это все host enviroment для JavaScript.
Мы бы поняли, что поведение этого API может не только отличаться в случае разных host сред, но и полностью отсутствовать. Об этом нужно помнить.
Например, метод console.log совсем не обязательно будет что-то показывать в реальной консоли host среды. host среда может так реализовать Printer что вывод методов нашего API будет лежать где-то в другом месте. Хоть в файле.
Представляет из себя API - namespace console насчитывающий ровно 19 методов:
Loggind: assert, clear, debug, error, info, log, table, trace, warn, dir, dirxml,
Counting: count, countReset,
Grouping: group, groupCollapsed, groupEnd,
Timing: time, timeLog, timeEnd.
API ориентировано, на работу с артефактами JavaScript спецификации, как следствие, поведение методов API максимально приближено к поведению JavaScript. Как следствие, утверждение автора о Отображение в реальном времени является выдумкой, свидетельствующей о плохом знании базы стандарта Ecma.
## Как работают методы API console
На самом деле, вывод любого метода рассматриваемого API, делает только то, что от него просят, а именно если вы отправили в метод идентификатор, то показана вам будет информация по идентификатору. Многие ошибаются, думая, что если они отправили в API идентификатор указывающий на обьект, то API им отправит в stdOut этот обьект. Это не так. В stdOut будет отправлено то, что вы и попросили - то есть то, что находится по ссылке из идентификатора. Подобное заблуждение распространено среди подавляющего большинства JS разработчиков, не знающих что в JS есть только один - ссылочный тип, идентификатор. Никаких переменных или чего либо другого характерного для других языков в JS нет.
Возможность "развернуть" "свернуть" обьекты это host implementation, то есть то, что решили сделать программисты конкретной host среды, в рамках реализации двух видов форматов спецификации для обьектов: optimally useful formatting и generic JavaScript object formatting. Которые, как мы уже понимаем, могут быть реализованы как вздумается программисту конкретной host.
## Метод Dir как пример
Показательным тому примером может служить глава про Метод Dir. Где автор материала демонстрирует как раз пример заблуждения возникшего в силу непонимания как и что работает. Метод Dir форматирует вывод в соотвествии с host implementation для формата generic JavaScript object formatting. То есть в формате который должен наглядно показать структуру обьекта. Метод log же использует optimally useful formatting, задача которого отформатировать вывод в оптимальный вид. Точнее говоря в тот вид, который программист Host считвет оптимальным. Иными словами, никакого форматирования в html, как сказано в статье там нет. А есть решение конкретной группы программистов в данном случае отформатировать вывод подобным образом.
Такие методы как profile, dir, debug, monitor и так далее - это специфические реализации Google Developer Tools. И к API console они никакого отношения не имеют. То есть они присутствуют только в нем и нигде больше.
## Игого
Я думаю, на примере сказанного мной выше, легко убедиться в обязательном чтении спецификации. Особенно для случаев подготовки материалов для общего пользования.
Полезные ссылки:
20+ консольных команд, которые изменят ваше представление об отладке