Вычислив объект, нужный для работы программы, вы сталкиваетесь с характерным рисунком своих желаний: значение хочется отложить в сторонку, чтобы в следующий раз не вычислять его снова, а воспользоваться прошлыми успехами.
Использование прошлых успехов, в переводе на исходный код, обычно сопровождается доступом к хранилищу по индексу. А вы знаете особенности идекс-оператора TypeScript?
В жизни каждого разработчика на TypeScript наступает момент, когда ему хочется рвать с все связи с типом any. А ведь по началу, он казался таким милым! Сделай переменной аннотацию типа any и используй любое свойство и метод этой переменной так, как привык работать в JavaScript. Никаких тебе ошибок, все чинно и спокойно, по-старому.
Документация TypeScript оправдывает использование any только на время переноса кодовой базы из JavaScript в TypeScript, но считает постыдным его использование в полноценном проекте. Казалось бы, все хорошо, только в описании типов библиотечных функций самого TypeScript аннотации any встречаются. Очень полезный JSON.parse, один из таких методов. Мы можем каждый раз писать as unknown, а можем доопределить библиотечный интерфейс.
С каждым годом TypeScript становится все популярнее и думаю уже почти каждый фронтенд разработчик использовал его в своих проектах.
В данной статье я бы хотел дать некоторые советы по использованию возможностей TypeScript, которые помогут вам сократить количество ошибок в процессе разработки.
Разбираемся на практике с тестированием собственных React-хуков с использованием TypeScript и React Testing Library, добиваясь 100%-го покрытия тестами.
Когда надоело запоминать ключи массивов и хочется пользоваться подсказками любимого редактора кода на помощь приходит PHPDoc и немного смекалки.
Недавно я очень близко познакомился с TypeScript и познал всю прелесть строгой типизации. Как же это приятно, когда редактор кода подсказывает тебе какие поля есть в объекте и что ты с ними можешь сделать!
В чем проблема?
Я работаю с CMS Битрикс и приходится иметь дело с массивами разной формы и содержания, запоминать все ключи или искать их в документации. Это занимает драгоценное время.
“И есть еще белые, белые дни, белые горы и белый лед.
Но все, что мне нужно - это несколько слов и место для шага вперед.”
(Виктор Цой)
Это вторая часть статьи, где будут вопросы, которые мне задавали и ответы на них. Я не берусь оценивать полезность вопросов и их смысл. Просто пишу все как есть, надо признать, что часть из них меня здорово обескуражили и мне пришлось уходить не солоно хлебавши, вспоминая один забавный анекдот:
"- Ну как на собеседование сходил? Успешно? - Да. Ручку у них спер" (ссылка)
Часть вопросов будет по typescript, часть по javascript, что-то будет из html, Node.js, настройки, библиотеки, концепции. В общем всё то, о чем говорят на собеседованиях.
Она помогла нам переиспользовать игровые механики в непохожих проектах и увеличила скорость разработки на 25%.
Обзорная статья, посвященная использованию инструментария Nx для разработки современных веб приложений с применением лучших практик. В статье приводится обзор возможностей Nx, а также приведены примеры создания различных библиотек и приложений для всевозможных нужд фронденд разработчика.
Думаю, что сейчас необходимость статической типизации фронтенд приложений не вызывает сомнений, не буду описывать все ее плюсы и минусы, так как на Хабр уже неоднократно обсуждалась данная тема. В данной статье бы хотел предложить решение, которое позволит выполнять проверку типов при создании HTML разметки во Vue.
Nest.js - популярный node.js фреймворк с отличной архитектурой, основанной на Angular.
Под капотом Nest использует надежные платформы HTTP-серверов, такие как Express (по умолчанию), и при желании также может быть настроен для использования Fastify! Nest обеспечивает уровень абстракции по сравнению с этими распространенными платформами Node.js (Express/Fastify), но также предоставляет свои API-интерфейсы непосредственно разработчику. Это дает разработчикам свободу использовать множество сторонних модулей, доступных для базовой платформы.
Использование Typescript при создании React компонента «Простой фабрики»
Создадим типизированный компонент-фабрику правильно. Так, чтобы он принимал только нужные параметры и ругался на некорректные. Данный подход применим и в других ситуацией, но сегодня рассмотрим компонент, который отрисует фигуру, которую мы захотим.
TypeScript — это язык, расширяющий JavaScript, добавляя в последний типизацию. Правда, так как TypeScript не имеет runtime-а (почти), он транслируется в JavaScript, в процессе чего, вся типизация теряется. Такую типизацию можно назвать лишь инструментом статического анализа кода. Тем не менее — это очень мощный инструмент. К тому же, помимо проверки кода, типизация также и документирует его.
В данной статье я расскажу лишь про типы, объявленные через ключевое слово type, не касаясь интерфейсов и классов. Однако, эта тема шире, чем может показаться, и я надеюсь, что читатель узнает что-то новое для себя. Ведь с помощью type можно писать маленькие программки (далее, утилиты), которые выполняются в процессе статического анализа кода, расширяя его возможности.
Во всех наших приложениях сотрудники могут общаться при помощи встроенного чата. При этом все чаще можно увидеть приложения, которые позволяют общаться пользователям по видеосвязи без перехода в сторонние сервисы.
В этой статье я расскажу про удобный способ создания такого функционала. Расскажу про готовые инструменты, опишу основные моменты, мысли, ссылки. Будет интересно!
Добрый день, меня зовут Павел Поляков, я Principal Engineer в каршеринг компании SHARE NOW, в Гамбурге в ?? Германии. А еще я автор телеграм канала Хороший разработчик знает, где рассказываю обо всем, что обычно знает хороший разработчик.
Сегодня я хочу поговорить про цену, которую мы платим, используя определенные свойства TypeScript. Использования каких возможностей TypeScript стоит избегать? Это перевод оригинальной статьи.
В данной статье мы рассмотрим текущее состояние экосистемы React, а также какие инструменты и библиотеки нам необходимы чтобы покрыть все основные кейсы для успешной разработки приложения.
“Не люблю темные стекла, сквозь них темное небо.
Дайте мне войти, откройте двери.”
(Виктор Цой)
Многим из нас время от времени приходиться менять работу и ходить по собеседованиям. На них соискателям задают каверзные вопросы, ответы на которые не всегда связанны непосредственно с кодированием и требуют более детального и глубокого погружения в предметную область. Сложно сказать насколько это необходимо на предлагаемом месте работы, но после некоторых особо запоминающихся собеседований, комичные ситуации описанные в интернете (ссылка) становятся немного грустными. Посетив разные фирмы в качестве соискателя на позицию Javascript разработчика, я решил поделиться ответами на вопросы, которые мне задавались. Статья состоит из двух частей. В первой части речь пойдет о том, как работает Javascript. Во второй части будет список вопросов с ответом на каждый из них.
Эксперименты с созданием редактора диаграмм на Blazor Webassembly (Blazor WebAssembly: Drag and Drop в SVG, Blazor WebAssembly: соединительные линии в SVG) показали что технология не годится для интенсивных манипуляций с DOM.
То что будут проседания было известно заранее: WebAssembly не имеет доступа к DOM, любые изменения только через вызовы JavaScript. Задержки оказались такими большими, что перетаскивание на мобильном тормозило уже после добавления третьей фигуры.
Добрый день, меня зовут Павел Поляков, я Principal Engineer в каршеринг компании SHARE NOW, в Гамбурге в ?? Германии. А еще я автор телеграм канала Хороший разработчик знает, где рассказываю обо всем, что обычно знает хороший разработчик.
Сегодня я хочу поговорить про React и JSX. Почти в каждом проекте мы пишем JSX шаблоны, которые рендерятся в зависимости от условий. Делаем ли мы это правильно? Это перевод оригинальной статьи.
"Ух-ты! Какая интересная задача! И оценка времени на разработку хорошая! ..."
2 часа спустя: "Какой же это ужас, ещё 10 редьюсеров создать, ещё 10 раз описать зависимости состояний. Типы, компоненты... Сколько же бесполезной рутины... Вот бы можно было писать только декларативную логику, всегда."
Если вам хоть отчасти близок текст выше, не переживайте, вы не одни такие. Я - человек который не один раз произнес сказаное выше.
Поэтому сегодня я поделюсь своими мыслями о том, как в моих глазах можно многое упростить, чтобы наконец начать получать хороший Developer Experience.
