Js почему вс код подчеркивает необработанный промис

Промисы: обработка ошибок

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

Например, в представленном ниже примере для fetch указана неправильная ссылка (сайт не существует), и .catch перехватывает ошибку:

fetch('https://no-such-server.blabla') // ошибка .then(response => response.json()) .catch(err => alert(err)) // TypeError: failed to fetch (текст может отличаться)

Как видно, .catch не обязательно должен быть сразу после ошибки, он может быть далее, после одного или даже нескольких .then

Или, может быть, с сервером всё в порядке, но в ответе мы получим некорректный JSON. Самый лёгкий путь перехватить все ошибки – это добавить .catch в конец цепочки:

fetch('/article/promise-chaining/user.json') .then(response => response.json()) .then(user => fetch(`https://api.github.com/users/$`)) .then(response => response.json()) .then(githubUser => new Promise((resolve, reject) => < let img = document.createElement('img'); img.src = githubUser.avatar_url; img.className = "promise-avatar-example"; document.body.append(img); setTimeout(() =>< img.remove(); resolve(githubUser); >, 3000); >)) .catch(error => alert(error.message));

Если все в порядке, то такой .catch вообще не выполнится. Но если любой из промисов будет отклонён (проблемы с сетью или некорректная json-строка, или что угодно другое), то ошибка будет перехвачена.

Неявный try…catch

Вокруг функции промиса и обработчиков находится «невидимый try..catch «. Если происходит исключение, то оно перехватывается, и промис считается отклонённым с этой ошибкой.

Например, этот код:

new Promise((resolve, reject) => < throw new Error("Ошибка!"); >).catch(alert); // Error: Ошибка!

…Работает так же, как и этот:

new Promise((resolve, reject) => < reject(new Error("Ошибка!")); >).catch(alert); // Error: Ошибка!

«Невидимый try..catch » вокруг промиса автоматически перехватывает ошибку и превращает её в отклонённый промис.

Это работает не только в функции промиса, но и в обработчиках. Если мы бросим ошибку ( throw ) из обработчика ( .then ), то промис будет считаться отклонённым, и управление перейдёт к ближайшему обработчику ошибок.

new Promise((resolve, reject) => < resolve("ок"); >).then((result) => < throw new Error("Ошибка!"); // генерируем ошибку >).catch(alert); // Error: Ошибка!

Это происходит для всех ошибок, не только для тех, которые вызваны оператором throw . Например, программная ошибка:

new Promise((resolve, reject) => < resolve("ок"); >).then((result) => < blabla(); // нет такой функции >).catch(alert); // ReferenceError: blabla is not defined

Финальный .catch перехватывает как промисы, в которых вызван reject , так и случайные ошибки в обработчиках.

Пробрасывание ошибок

Как мы уже заметили, .catch ведёт себя как try..catch . Мы можем иметь столько обработчиков .then , сколько мы хотим, и затем использовать один .catch в конце, чтобы перехватить ошибки из всех обработчиков.

В обычном try..catch мы можем проанализировать ошибку и повторно пробросить дальше, если не можем её обработать. То же самое возможно для промисов.

Если мы пробросим ( throw ) ошибку внутри блока .catch , то управление перейдёт к следующему ближайшему обработчику ошибок. А если мы обработаем ошибку и завершим работу обработчика нормально, то продолжит работу ближайший успешный обработчик .then .

В примере ниже .catch успешно обрабатывает ошибку:

// the execution: catch -> then new Promise((resolve, reject) => < throw new Error("Ошибка!"); >).catch(function(error) < alert("Ошибка обработана, продолжить работу"); >).then(() => alert("Управление перейдёт в следующий then"));

Здесь блок .catch завершается нормально. Поэтому вызывается следующий успешный обработчик .then .

В примере ниже мы видим другую ситуацию с блоком .catch . Обработчик (*) перехватывает ошибку и не может обработать её (например, он знает как обработать только URIError ), поэтому ошибка пробрасывается далее:

// the execution: catch -> catch -> then new Promise((resolve, reject) => < throw new Error("Ошибка!"); >).catch(function(error) < // (*) if (error instanceof URIError) < // обрабатываем ошибку >else < alert("Не могу обработать ошибку"); throw error; // пробрасывает эту или другую ошибку в следующий catch >>).then(function() < /* не выполнится */ >).catch(error => < // (**) alert(`Неизвестная ошибка: $`); // ничего не возвращаем => выполнение продолжается в нормальном режиме >);

Управление переходит от первого блока .catch (*) к следующему (**) , вниз по цепочке.

Необработанные ошибки

Что произойдёт, если ошибка не будет обработана? Например, мы просто забыли добавить .catch в конец цепочки, как здесь:

new Promise(function() < noSuchFunction(); // Ошибка (нет такой функции) >) .then(() => < // обработчики .then, один или более >); // без .catch в самом конце!

В случае ошибки выполнение должно перейти к ближайшему обработчику ошибок. Но в примере выше нет никакого обработчика. Поэтому ошибка как бы «застревает», её некому обработать.

На практике, как и при обычных необработанных ошибках в коде, это означает, что что-то пошло сильно не так.

Что происходит, когда обычная ошибка не перехвачена try..catch ? Скрипт умирает с сообщением в консоли. Похожее происходит и в случае необработанной ошибки промиса.

JavaScript-движок отслеживает такие ситуации и генерирует в этом случае глобальную ошибку. Вы можете увидеть её в консоли, если запустите пример выше.

В браузере мы можем поймать такие ошибки, используя событие unhandledrejection :

window.addEventListener('unhandledrejection', function(event) < // объект события имеет два специальных свойства: alert(event.promise); // [object Promise] - промис, который сгенерировал ошибку alert(event.reason); // Error: Ошибка! - объект ошибки, которая не была обработана >); new Promise(function() < throw new Error("Ошибка!"); >); // нет обработчика ошибок

Это событие является частью стандарта HTML.

Если происходит ошибка, и отсутствует её обработчик, то генерируется событие unhandledrejection , и соответствующий объект event содержит информацию об ошибке.

Обычно такие ошибки неустранимы, поэтому лучше всего – информировать пользователя о проблеме и, возможно, отправить информацию об ошибке на сервер.

В не-браузерных средах, таких как Node.js, есть другие способы отслеживания необработанных ошибок.

Итого

.catch перехватывает все виды ошибок в промисах: будь то вызов reject() или ошибка, брошенная в обработчике при помощи throw .
.then также перехватывает ошибки таким же образом, если задан второй аргумент (который является обработчиком ошибок).
Необходимо размещать .catch там, где мы хотим обработать ошибки и знаем, как это сделать. Обработчик может проанализировать ошибку (могут быть полезны пользовательские классы ошибок) и пробросить её, если ничего не знает о ней (возможно, это программная ошибка).
Можно и совсем не использовать .catch , если нет нормального способа восстановиться после ошибки.
В любом случае нам следует использовать обработчик события unhandledrejection (для браузеров и аналог для других окружений), чтобы отслеживать необработанные ошибки и информировать о них пользователя (и, возможно, наш сервер), благодаря чему наше приложение никогда не будет «просто умирать».

Async/await: 6 причин забыть о промисах

Если вы не в курсе, в Node.js, начиная с версии 7.6, встроена поддержка механизма async/await. Говорят о нём, конечно, уже давно, но одно дело, когда для использования некоей функциональности нужны «костыли», и совсем другое, когда всё это идёт, что называется, «из коробки». Если вы ещё не пробовали async/await — обязательно попробуйте.

Сегодня мы рассмотрим шесть особенностей async/await, позволяющих отнести новый подход к написанию асинхронного кода к разряду инструментов, которые стоит освоить и использовать везде, где это возможно, заменив ими то, что было раньше.

Основы async/await

Для тех, кто не знаком с async/await, вот основные вещи, которые полезно будет знать прежде чем двигаться дальше.

Синтаксис

Представим, что у нас имеется функция getJSON , которая возвращает промис, при успешном разрешении которого возвращается JSON-объект. Мы хотим эту функцию вызвать, вывести в лог JSON-объект и вернуть done .

С использованием промисов подобное можно реализовать так:

const makeRequest = () => getJSON() .then(data => < console.log(data) return "done" >) makeRequest()

Вот как то же самое делается с использованием async/await:

const makeRequest = async () => < console.log(await getJSON()) return "done" >makeRequest()

Если сопоставить два вышеприведённых фрагмента кода, можно обнаружить следующее:

// Эта конструкция на верхнем уровне кода работать не будет // await makeRequest() // А такая - будет makeRequest().then((result) => < // do something >)

Почему async/await лучше промисов?

Рассмотрим обещанные шесть преимуществ async/await перед традиционными промисами.

▍1. Лаконичный и чистый код

Сравнивая два вышеприведённых примера, обратите внимание на то, насколько тот, где используется async/await, короче. И ведь речь, в данном случае, идёт о маленьких кусках кода, а если говорить о реальных программах, экономия будет ещё больше. Всё дело в том, что не нужно писать .then , создавать анонимную функцию для обработки ответа, или включать в код переменную с именем data , которая нам, по сути, не нужна. Кроме того, мы избавились от вложенных конструкций. Полезность этих мелких улучшений станет заметнее, когда мы рассмотрим другие примеры.

▍2. Обработка ошибок

Конструкция async/await наконец сделала возможной обработку синхронных и асинхронных ошибок с использованием одного и того же механизма — старого доброго try/catch . В следующем примере с промисами try/catch не обработает сбой, возникший при вызове JSON.parse , так как он выполняется внутри промиса. Для обработки подобной ошибки нужно вызвать метод .catch() промиса и продублировать в нём код обработки ошибок. В коде рабочего проекта обработка ошибок будет явно сложнее вызова console.log из примера.

const makeRequest = () => < try < getJSON() .then(result =>< // парсинг JSON может вызвать ошибку const data = JSON.parse(result) console.log(data) >) // раскомментируйте этот блок для обработки асинхронных ошибок // .catch((err) => < // console.log(err) // >) > catch (err)

Вот то же самое, переписанное с использованием async/await. Блок catch теперь будет обрабатывать и ошибки, возникшие при парсинге JSON.

const makeRequest = async () => < try < // парсинг JSON может вызвать ошибку const data = JSON.parse(await getJSON()) console.log(data) >catch (err) < console.log(err) >>

▍3. Проверка условий и выполнение асинхронных действий

Представьте, что надо написать кусок кода, который, загрузив некие данные, принимает решение о том, вернуть ли их в точку вызова, или, основываясь на том, что уже получено, запросить ещё что-нибудь. Решить подобную задачу можно так:

const makeRequest = () => < return getJSON() .then(data => < if (data.needsAnotherRequest) < return makeAnotherRequest(data) .then(moreData =>< console.log(moreData) return moreData >) > else < console.log(data) return data >>) >

Только от взгляда на эту конструкцию может разболеться голова. Очень легко потеряться во вложенных конструкциях (тут их 6 уровней), скобках, командах возврата, которые нужны лишь для того, чтобы доставить итоговый результат главному промису.

Код будет гораздо легче читать, если решить задачу с использованием async/await.

const makeRequest = async () => < const data = await getJSON() if (data.needsAnotherRequest) < const moreData = await makeAnotherRequest(data); console.log(moreData) return moreData >else < console.log(data) return data >>

▍4. Промежуточные значения

Возможно, вы встречались с ситуацией, когда вы вызываете promise1 , затем используете то, что он возвращает, для вызова promise2 , потом задействуете оба результата от ранее вызванных промисов для вызова promise3 . Вот как будет выглядеть код, решающий такую задачу.

const makeRequest = () => < return promise1() .then(value1 => < // do something return promise2(value1) .then(value2 =>< // do something return promise3(value1, value2) >) >) >

Если для promise3 не нужно value1 , можно без особых сложностей упростить структуру программы, особенно если вам режут глаз подобные конструкции, использованные без необходимости. В такой ситуации можно обернуть value1 и value2 в вызов Promise.all и избежать ненужных вложенных конструкций.

const makeRequest = () => < return promise1() .then(value1 =>< // do something return Promise.all([value1, promise2(value1)]) >) .then(([value1, value2]) => < // do something return promise3(value1, value2) >) >

При таком подходе семантика приносится в жертву читабельности кода. Нет причин для того, чтобы помещать value1 и value2 в один и тот же массив за исключением того, чтобы избежать вложенности промисов.

То же самое можно написать с применением async/await, причём делается это удивительно просто, а то, что получается, оказывается интуитивно понятным. Тут поневоле задумаешься о том, сколько полезного можно сделать за то время, которое тратится на написание хоть сколько-нибудь приличного кода с использованием промисов.

const makeRequest = async () =>

▍5. Стеки ошибок

Представьте себе фрагмент кода, в котором имеется цепочка вызовов промисов, а где-то в этой цепочке выбрасывается ошибка.

const makeRequest = () => < return callAPromise() .then(() =>callAPromise()) .then(() => callAPromise()) .then(() => callAPromise()) .then(() => callAPromise()) .then(() => < throw new Error("oops"); >) > makeRequest() .catch(err => < console.log(err); // вывод // Error: oops at callAPromise.then.then.then.then.then (index.js:8:13)

Стек ошибки, возвращённый из цепочки промисов, не содержит указания на то, где именно произошла ошибка. Более того, сообщение об ошибке способно направить усилия по поиску проблемы по по ложному пути. Единственное имя функции, которое содержится в сообщении — callAPromise , а эта функция никаких ошибок не вызывает (хотя, конечно, тут есть и полезная информация — сведения о файле, где произошла ошибка, и о номере строки).

Если же взглянуть на подобную ситуацию при использовании async/await, стек ошибки укажет на ту функцию, в которой возникла проблема.

const makeRequest = async () => < await callAPromise() await callAPromise() await callAPromise() await callAPromise() await callAPromise() throw new Error("oops"); >makeRequest() .catch(err => < console.log(err); // вывод // Error: oops at makeRequest (index.js:7:9) >)

Подобное нельзя назвать огромным плюсом, если речь идёт о разработке в локальном окружении, когда файл с кодом открыт в редакторе. Но это оказывается весьма полезным, если вы пытаетесь понять причину ошибки, анализируя лог-файл, полученный с продакшн-сервера. В подобных случаях знать, что ошибка произошла в makeRequest , лучше, чем знать, что источник ошибки — некий then , вызванный после ещё одного then , который следует за ещё каким-то then …

▍6. Отладка

Этот пункт последний, но это не значит, что он не особо важен. Ценнейшая особенность использования async/await заключается в том, что код, в котором задействована эта конструкция, гораздо легче отлаживать. Отладка промисов всегда была кошмаром по двум причинам.

1. Нельзя установить точку останова в стрелочных функциях, которые возвращают результаты выполнения выражений (нет тела функции).

Попробуйте поставить где-нибудь в этом коде точку останова

2. Если вы установите точку останова внутри блока .then и воспользуетесь командой отладчика вроде «шаг с обходом» (step-over), отладчик не перейдёт к следующему .then , так как он может «перешагивать» только через синхронные блоки кода.

При использовании async/await особой нужды в стрелочных функциях нет, и можно «шагать» по вызовам, выполненным с ключевым словом await так же, как это делается при обычных синхронных вызовах.

Отладка при использовании async/await

Замечания

Вполне возможно, у вас возникнут некоторые соображения не в пользу применения async/await, продиктованные здоровым скептицизмом. Прокомментируем пару наиболее вероятных.

Эта конструкция делает менее очевидными асинхронные вызовы.

Выводы

Пожалуй, async/await — это одна из самых полезных революционных возможностей, добавленных в JavaScript в последние несколько лет. Она даёт простые и удобные способы написания и отладки асинхронного кода. Полагаем, async/await пригодится всем, кому приходится писать такой код.

Уважаемые читатели! Как вы относитесь к async/await? Пользуетесь ли вы этой возможностью в своих проектах?

Блог компании RUVDS.com
JavaScript
Node.JS

17 полезных плагинов JavaScript в VS Code

Редактор кода Visual Studio Code помогает быстрее писать код, например, он подчёркивает ошибки красным цветом и показывает подсказки. Но работу можно сделать ещё приятнее, если установить нужное расширение.

Плагинов VS Code много. Здесь мы расскажем об одних из самых популярных — они пригодятся при работе с JavaScript.

ESLint

Проверяет код на синтаксические ошибки и предлагает исправления.

Конечно, в VS Code уже есть встроенная система IntelliSense, которая показывает подсказки. Но ESLint больше подходит, например, если вам нужны разные настройки — для JSX, для чистого JS, для среды Node.js. Ещё линтер можно встроить в систему проверки кода и перед отправкой файлов в репозиторий ещё раз убедиться, что всё в порядке.

Better Align

Выравнивает переменные, свойства объекта и другие элементы кода по операторам : , = , += , -= , *= , /= или по стрелке => . При этом длина переменных не важна.

EditorConfig

Расширение помогает разработчикам, которые работают над одним проектом, придерживаться единого стиля кода. EditorConfig перезаписывает настройки пользователя и рабочего окружения, заменяя их настройками, найденными в файлах .editorconfig .

Prettify JSON

Расширение форматирует файлы в формате JSON.

JavaScript (ES6) code snippets

Этот сниппет ускоряет разработку: вы вводите короткое сочетание клавиш, а вместо них появляется целая строка кода. Например, команда enf вызовет export const log = (parameter) => < console.log (parameter); >.

npm Intellisense

Пригодится при разработке под Node.js. Начните писать название модуля — по первым символам плагин подскажет варианты.

Git History

С его помощью можно посмотреть историю изменений коммита, файла или строки, увидеть предыдущую копию файла, сравнить ветки и коммиты. Ещё расширение покажет имя и электронную почту автора изменения.

Project Manager

Когда вы работаете сразу над несколькими проектами, приходится переключаться между ними — это не всегда удобно. Project Manager решает эту проблему. С ним вы можете создавать, открывать, закрывать и быстро переключаться между различными проектами прямо из интерфейса Visual Studio Code.

Document this

Плагин пригодится, чтобы не писать заготовки будущих комментариев вручную и автоматизировать процесс.

Todo+

Обычно участки кода, которые планируется позже отрефакторить, помечают комментарием TODO. Могут быть и другие комментарии, например, FIXME, NOTE. Тodo+ сканирует файл и выводит все комментарии на отдельную панель.

REST Client

Позволяет отправлять HTTP-запросы и сразу же просматривать на них ответы. Например, для отправки GET-запроса достаточно ключевого слова GET и URL — рядом появится кнопка. При нажатии откроется отдельная вкладка с результатом выполнения запроса.

VSCode-random

Подойдёт, если вам нужен набор сгенерированных данных. Расширение включает несколько генераторов, которые выдают названия стран, URL-адреса, цвета, имена людей, названия улиц, валидные email, случайные числа и ещё много другого. Всё проще, чем готовить такие данные самостоятельно.

Import Cost

Пакеты в NPM (менеджере пакетов) могут быть очень объёмными. С помощью этого расширения можно увидеть размер пакета после подключения прямо в редакторе и выбрать оптимальный. А ещё вы можете задать порог — и пакеты тяжелее этого порога подсветятся красным.

Code Runner

Благодаря плагину вы сможете запустить код или сниппет на многих языках. Например, C, C++, Java, JavaScript, PHP, Python.

Snippets

Сниппеты — сокращения для часто используемых фрагментов кода. Их нужно сначала заучить, но после этого работа сильно ускоряется. Например, вам больше не нужно каждый раз писать const packageName = require('packageName'); — достаточно написать req и нажать клавишу tab . И таких примеров много.

Tabnine AI

Нейросеть поможет ускорить работу благодаря автодополнению кода. Аналог GitHub Copilot и других подобных сервисов.

Handlebars/Handlebars Preview, pug/htmlPugConverter

Помогают в работе с популярными шаблонизаторами handlebars и Pug.

Handlebars подсвечивает синтаксис.

Handlebars Preview быстро компилирует шаблон Handlebars и показывает результат в окне предварительного просмотра.

htmlPugConverter упрощает конвертацию HTML в синтаксис Pug и обратно.

pug — сниппет для шаблонизатора Puge/Jade.

Попробуйте эти расширения при работе с JavaScript сами. Вот увидите — жизнь станет намного проще. А если не понравится, любой плагин можно удалить — как и установить — в один клик.

Материалы по теме

Обзор редакторов кода
10 библиотек для CSS и JS анимации
Топ-20 плагинов для Figma
Как искать и выбирать npm-пакеты
HTML-шаблонизаторы

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

Читать дальше

Figma Dev Mode становится платным. Всё пропало?

Если вы всё пропустили, то на днях в Фигме появилась такая плашка:

Коротко: Dev Mode, скоро выходит из бета-версии и станет платным. Dev Mode — это тот новый режим, который умеет удобно сразу показывать весь нужный CSS и свойства в одном месте. Мы уже рассказывали о нём в «Доктайпе».

Но прошло полгода и лавочка закрылась. Отвечаем на самые распространенные вопросы, которые могли у вас появиться (потому что они появились и у нас).

30 января 2024

Dev Mode в Figma. Быстрый обзор бета-версии

Если вы читаете эту статью, Dev Mode в Figma наконец-то вышел в открытую бету. Быстренько рассказываем, что это такое, и как его включить и настроить.

Раньше верстальщикам была доступна только вкладка Inspect с базовой информацией о стилях конкретного элемента.

Некоторые разработчики не рекомендовали копировать стили оттуда, потому что всегда это работало с нюансами. Пока сложно сказать, насколько стили стали точнее, но работать стало определённо удобнее. Сами Adobe называют Figma новым пространством для разработчиков, с возможностями, которые помогают быстрее переводить дизайн в код. Давайте проверим.

10 августа 2023

Горячие клавиши Figma для быстрой работы

Figma — это инструмент для создания дизайна, который очень любят веб-разработчики. Одна из причин, почему Figma так популярна — это горячие клавиши. Они помогают работать быстрее и проще. Давайте рассмотрим самые важные из них.

Скрыть или показать интерфейс Фигмы (Ctrl + \ или ⌘ + \ для Mac)

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

Быстрый поиск по меню (Ctrl + / или ⌘ + / для Mac)

Эта комбинация клавиш открывает поиск по меню. Это очень удобно, когда вы знаете, что вам нужно, но не помните, где это находится. Просто начните вводить то, что вы ищете, и Figma покажет вам нужный пункт меню. Если пользуетесь Spotlight или PowerToys, вам будет очень удобно.

А если не пользуетесь — попробуйте.

7 августа 2023

Старт в Figma для верстальщика

Figma — это онлайн-редактор графики для дизайнеров интерфейсов и веб-разработчиков. Это удобная, бесплатная альтернатива Photoshop.

Большое преимущество платформы — возможность работать прямо в браузере. При этом есть и десктопная версия. Расскажем, что надо знать верстальщику при работе с макетом в Figma.

2 августа 2023

Инструменты для работы со шрифтами

Работа со шрифтами и типографикой — важная часть вёрстки текста. Новые шрифты появляются очень часто, за этим сложно уследить. Существует множество инструментов, которые помогают находить нужные шрифты, управлять ими и улучшать внешний вид текста.

Рассмотрим несколько инструментов для работы со шрифтами, которые будут полезны при создании сайта.

29 июня 2023

10 горячих клавиш VS Code, которые ускорят вашу работу

Горячие клавиши — добро, польза и экономия времени. Давайте разберёмся, как с их помощью упростить себе жизнь в Visual Studio Code.

13 июня 2023

10 лучших тем для VS Code

VS Code — популярный редактор кода со множеством полезных инструментов. Сегодня мы поделимся с вами 10 темами, чтобы работать стало ещё приятнее. Выбирайте на свой вкус и цвет.

11 июня 2023

10 полезных плагинов VS Code для вёрстки

Visual Studio Code — один из самых популярных редакторов кода. Его удобно использовать, и у него есть множество полезных расширений, с помощью которых легко оптимизировать работу. Такие плагины помогают допускать меньше ошибок при написании кода, да и значительно сокращают время работы.

Чтобы установить расширения, перейдите во вкладку «Extensions» и в поиске найдите подходящие плагины.

9 июня 2023

Подборка микроанимаций для фронтенда с CodePen в 2023

⭐ Микроанимация — короткое взаимодействие, которое помогает пользователю лучше сориентироваться в интерфейсе и почувствовать совершенное действие.

Например, нажатие на кнопку лайка в социальных сетях или изменение фона, индикатор загрузки, и многое другое. Микроанимация используется везде, где есть интерфейс пользователя, а именно, веб-сайтах, мобильных приложениях, играх. На примерах с CodePen покажем, какими они бывают.

12 апреля 2023

Как собрать проект на Webpack

Webpack — это сборщик модулей для JavaScript-приложений. Он позволяет разделять код на модули, которые затем могут быть импортированы и использованы в других частях приложения. Это полезно для структурирования кода, оптимизации производительности и поддержки сторонних библиотек.

Подробнее о Webpack мы писали в другой статье, а пока давайте создадим простой проект, который складывает два числа, а заодно научимся пользоваться Webpack.

7 апреля 2023

Настройка TypeScript в .js файлах в Visual Studio Code

Для исправления ошибки 'types' можно использовать только в .ts файле в JavaScript предлагается воспользоваться директивой @ts-check и комментариями JSDoc, отказавшись от использования синтаксиса TypeScript. Вот пример решения:

Скопировать код

// @ts-check /** @type */ let myString; // Объявляем переменную с типом string myString = 'Привет'; // Код работает исправно! // myString = 42; // Остановитесь! VS Code выдаст ошибку из-за несоответствия типов.

Такой подход позволяет применять типизацию в JavaScript файлах, используя встроенное в Visual Studio Code средство проверки типов, без перехода на TypeScript.

Максимизация использования проверки типов в Visual Studio Code

Правильная настройка проверки типов в JavaScript посредством @ts-check существенно упрощает разработку в Visual Studio Code (VS Code).

Настройка проверки типов в VS Code

Для бесперебойной работы следует придерживаться нижеуказанных рекомендаций:

Отключите обычные компоненты: Деактивируйте в панели расширений функцию "TypeScript and JavaScript Language Features", чтобы избежать возникновения конфликтов с настройками.
Настройка ассоциаций файлов: Разработчикам на React стоит изменить ассоциации файлов *.tsx и *.ts на typescriptreact в настройках для корректного распознавания.
Изменение settings.json: Дополните файл settings.json строками "javascript.validate.enable": false и "js/ts.implicitProjectConfig.checkJs": true для отключения стандартной проверки JS и активации проверки типов для JavaScript файлов вне TypeScript проектов.
Порядок расширений: Разместите главные расширения, например ESLint и TSLint, в начале списка, чтобы предотвратить конфликты и улучшить работу с кодом.
Добавление нужных расширений: Если вы используете Flow, добавьте расширение Flow Language Support и настройте ESLint и TSLint для оптимизации работы IntelliSense.

Достижение надёжной проверки ошибок

Чтобы извлечь максимум из возможностей проверки типов и отлавливания ошибок в VS Code, рекомендуется:

Настройка плагинов ESLint и TSLint: Подробнее изучите настройки этих инструментов для эффективного обнаружения ошибок.
Интеграция Flow: При использовании Flow ознакомьтесь с руководством по настройке для удачной интеграции.

Следование этим рекомендациям поможет вам оптимизировать работу в VS Code и приспособить его к своим нуждам при разработке на JavaScript.

Визуализация

Для наглядного понимания работы с аннотациями types в TypeScript (.ts) и использования @ts-check в JavaScript (.js) рассмотрим следующие примеры: