Добрый день, коллеги, такой вопрос: встроенные средства для отладки в Chrome/FF куда удобней, привычней и все вот это вот, чем встроееный дебаг в php/webstorm, тем более в браузер передаются уже собранные гульпом/вебпаком файлы и точки останова в исходниках не работают (может руки кривые, первый раз настраивал). Я ни разу не пользовался до сих пор этим функционалом и настроив не увидел никаких плюсов данного подхода, скорее наоборот, так как в нем много чего отсутствует . Объясните - я действительно теряю какие-либо преимущества не используя этот функционал IDE или он вправду бесполезен и проигрывает браузерам?
Так же реквестирую советы по дебагу яваскрипта, фичи, может я что-то упускаю помимо
tyzberd, ну вот к этому претензий нет, это бесспорно Stalker_RED, фиг с ними, это не самая большая проблема, очевидные плюсы какие? Навскидку, в ide удобней брейкпоинт поставить, чем искать в файлах. Но это вопрос пары минут. Других преимуществ не вижу
Представьте себе такой кейс. Вы пишете компонент, нажимаете ctrl+s, у Вас запускается вотчер, перезагружается браузер и ничего. Код не работает. Вы альттабатесь в браузер, жмакаете f12, console, видите ошибку, заходите в source находите файл, ставите брейкпоинт, понимаете где ошибка и возвращаетесь в Webstorm.
Так вот в WebStorm вы уже находитесь в контексте своего нерабочего компонента, так почему бы не запустить дебагер прям компонента, для этого нужно нажать одну кнопку и сразу увидеть где у Вас проблема и прям на месте поправить. Звучит проще по крайней мере
Не так. В случае дебага в ИДЕ
1. вы пишете компонент, сохраняете
2. идете в браузер, видите что какая-то часть сайта пошла наперекосяк
3. открываете ИДЕ, пытаетесь вспомнить где это было, не получается
4. открываете браузер, в девтулзах DOM кликаете по страничке, ищете компонент, идете в source, ищете какой-это файл
5. ищете и открываете файл в ИДЕ, ставите брейк,
6. открываете браузер, перезагружаете страницу,
7. возвращаетесь в иде, смотрите на результат брейка,
8. повторяете операцию до полного прояснения ситуации
9. в итоге меняете код, проверяете.
А в случае отладки в браузере шаги 3-8 происходят не вылезая из браузера, без лишних метаний туда сюда и очень быстро.
Один минус - нельзя на месте код поправить. пункт 5 переезжает в пункт 9. Но поиск причины обычно занимает больше времени, чем редактирование.
Можно ставить брейки и смотреть состояние там же, где пишешь код. По-моему это все.
Я так же не нашел для себя плюсов, в браузере удобнее, можно юзать $0 и прочие браузерные фишки с DOM, и, если есть сурсмапы, браузер так же отображает неупакованные исходники и ставит брейки в них.
Средний
