TypeScript *

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

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

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

TypeScript — стандарт современной фронтенд-разработки. Согласно исследованиям State of JavaScript, TS вызывает явный интерес у программистов. По данным опроса за 2019 год, почти 60% респондентов пробовали TS и продолжают использовать, 22% не пробовали и желают изучить.

Эта статья — сборник советов о том, как внедрить и улучшить использование TypeScript. Первая половина советов общая, касающаяся подходов и инфраструктуры. Вторая — несколько особо полезных фишек языка.

Недавно мне повезло попасть на проект бэкенд которого написан на php. А как принято у php бекэндов json с ответом они отправляют в snake case стиле. И как следствие вся работа с данными на фронте происходила в перемешку в camel case и snake case стилях. Для решения этой проблемы была доработана библиотека сериализации ts-serializable. Теперь при получении данных из json их можно приводить к принятому в js стилю camel case, а при отправке на сервер возвращать в snake case.



Так же после выхода первой версии у некоторых пользователей были пожелания по функционалу. Эти пожелания реализованы в новой версии.

Порой разработчики во время работы придумывают безумные идеи проектов, и они даже пытаются их реализовывать. Подобное ощутил и фулстек-разработчик Дмитрий Пацура, когда решил написать компилятор для TypeScript на… TypeScript, используя LLVM.

А что из этого вышло, Дмитрий изложил на прошедшей HolyJS 2019 Moscow. Под катом вы найдете видео и конспект его доклада.

Привет, Хабр!

В последнее время в области front-end особую популярность приобретает комбинация React+TypeScript. Соответственно, возрастает актуальность грамотной миграции с JavaScript на TypeScript, желательно в сжатые сроки. Сегодня мы хотели бы обсудить с вами именно эту тему.

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



Демо и документация
Github
Плагин для React

Подобный эффект я реализовывал данным давно, еще в университете и на Delphi. Получилось вполне достойно, правда времени я потратил тогда очень много. Сейчас, во время самоизоляции, стало интересно реализовать что-то подобное на JS, для PC и мобильных устройств.

Признаться честно, я не уверен в практической применимости данного эффекта, и думаю что в большинстве случаев, нет ничего лучше простой смены картинок без всякой анимации. Но это вполне можно использовать, допустим на сайтов ресторанов, для публикации меню (но главное — что бы рядом дублировалось ссылкой!).

Написано все на Typescript. Не использовались ни какие сторонние библиотеки. Зависимостей нет.

Ключевые особенности библиотеки

• Работает как с простыми изображениями, с отрисовкой на canvas, так и с html блоками — используя css трансформации
• Довольно гибкая система конфигурации и простое API
• Поддерживает мобильные устройства
• Автоматическая смена ориентации между портретным и ландшафтным режимом

Когда мой проект на Vue начал разрастаться и достиг нескольких сотен компонентов, я задумался о подходе Vue и Vuex к архитектуре проекта.

Привет, Хабр! Меня зовут Богдан, я работаю в ПИК Digital Front-End тимлидом. Большую часть проектов мы разрабатываем на Angular и недавно я решил пересмотреть наши стайл гайды, а также добавить новые инструменты для более удобной работы.

В качестве линтера я решил использовать ESLint, так как в скором времени на него планируют перевести Angular. И в этой статье я хочу поделиться инструкцией по переходу с TSLint на ESLint, а заодно рассказать, как запускать Prettier из ESLint, как добавить правила стайл гайда AirBnB, и как сделать линтинг удобным и незаметным с помощью настройки VS Code и Git хуков.

Мы, разработчики, очень любим юнит-тесты, полезность которых очевидна. И чтобы эти тесты действительно были полезными, а не приносили боль, необходимо обеспечивать их стабильность.

Наша компания разрабатывает интерфейсный фреймворк "Wasaby" и продает построенные на его базе продукты, представляющие собой облачные и десктопные приложения. Релизный цикл у нас жестко привязан к календарю, а для контроля качества продукта настроены процессы непрерывной инеграции. Мы используем Jenkins для сборок и Mocha в связке с Chai assert для юнит тестирования JavaScript кода. И недавно мы столкнулись с ситуацией, когда мониторинг сборок стал показывать, что примерно половина всех случаев их падения приходится на нестабильные юнит-тесты JavaScript. Симптоматика при этом одинаковая: отдельный тест из набора либо не успевает выполниться, либо возвращает не тот результат, что ожидается. И анализ кейсов практически всегда выявляет факт, что падает тест, содержащий вызовы функций setTimeout или setInterval в собственном, либо в тестируемом коде. О том, как правильно поступить в этой ситуации, мы и будем говорить дальше.

1. Вступление
2. Установка
3. Как это выглядит внутри
4. Функциональность
5. WASM, RUST, Плагины
6. Debugging, IDE
7. Тестирование
8. Compiler API
9. CI
10. Разное

Вступление

Если вы уже оказались за чтением этой статьи, то наверняка уже слышали про выступление Ryan Dahl, создателя NodeJS, на JSConf, где он выступил с докладом и рассказал о ключевых ошибках, которые были сделаны при проектировании NodeJS. В этом же докладе он обьявил о новом проекте: Deno, в котором будут учтены ошибки предыдущего проектирования.

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

Всем привет, меня зовут Владимир. Я занимаюсь фронтенд разработкой в Tinkoff.ru.

В Ангуляре для передачи данных внутри приложения или для инкапсуляции бизнес-логики мы привыкли использовать сервисы. Для управления асинхронными потоками отлично подходит RxJS.

Ангуляр в сочетании с RxJS позволяет писать в декларативном стиле, коротко и ясно. Но иногда мы сталкиваемся со сторонними библиотеками или API, которые используют коллбэки, промисы, тем самым подталкивают нас отступить от привычного стиля и писать императивно.

Цель статьи — показать на примере подобных API, как с помощью RxJS их можно без проблем обернуть в Observable-сервисы. Это поможет достичь удобства использования в Ангуляре. Начнем с Geolocation API.

В программировании очень много вещей, в которых я разбираюсь очень плохо. Настолько много, что меня иногда спрашивают — а в чем ты вообще разбираешься?

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

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

Относительная простота и доступность Javascript, относительная легкость входа в него предопределила на многие годы вперед его популярность. Некоторые языки программирования существенно повлияли на развитие всей отрасли в целом. Так, например SmallTalk стал неким прадедушкой ООП и объектного подхода, хоть сам по себе мало где используется. А Javascript… на мой взгляд это язык, о потенциале которого создатели не имели должного представления. Но мне всегда хотелось работать с чем-то на стыке между гибкостью  Javascript и строгостью типизированных языков. Возможно ли это?

В добрых традициях хабра я хочу сразу оговориться, что не претендую на применимость в 100% случаев, и не считаю мое мнение единственно верным. Приведенное ниже — мой взгляд и отношение к программированию вообще и к написанию кода на TS/JS в частности. Кроме статьи, я этот взгляд постарался донести на митапе, запись которого доступна тут.

Хочу поделиться с вами подходом который я уже много лет использую в разработке приложений, в том числе и веб-приложений. Многим разработчикам настольных, серверных и мобильных приложений этот подход хорошо знаком, т.к. является фундаментальным при построении таких приложений, однако в вебе он представлен очень скудно, хотя желающие использовать такой подход однозначно есть. Кроме того на таком подходе написан редактор VS Code.



В результате применения этого подхода вы отвяжетесь от конкретного фреймворка. Сможете легко переключать библиотеку представления внутри вашего приложения, например React, Preact, Vue, Mithril без переписывания бизнес логики, а в большинстве случаев даже вьюхи. Если у вас есть приложение на Angular 1, вы без проблем сможете перевести его на Angular 2+, React, Svelte, WebComponents или даже свою библиотеку представления. Если у вас есть приложение на Angular 2+, но нету специалистов для него, то вы без проблем сможете перевести приложение на более популярную библиотеку без переписывания бизнес логики. А в итоге вообще забыть про проблему миграции с фремворка на фреймворк. Что же это за магия такая?

Привет, Хабр! Предлагаю вашему вниманию перевод статьи Implementing SOLID and the onion architecture in Node.js with TypeScript and InversifyJS автора Remo H. Jansen

В этой статье мы рассмотрим архитектуру, известную как слоистая (onion). Слоистая архитектура — подход к построению архитектуры приложения, придерживающийся принципов SOLID. Он создан под влиянием DDD и некоторых принципов функционального программирования, а также, активно применяет принцип инъекции зависимостей.

Предпосылки

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

Принцип разделения ответственности

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

В прошлом году я в свободное время написал сборник упражнений по TypeScript для своей команды, чтобы помочь ребятам подтянуть свой уровень. В этом году доработал напильником и решил выложить в общий доступ. Задания начинаются с простых и заканчиваются очень сложными, где нужны не только знания TypeScript, но и знания node.js.

Вот ссылка на репозиторий

Пользуйтесь на здоровье. Можете слать мне пулл-реквесты и задавать вопросы. Фидбек приветствуется.

React-фронтенд Execute Program перевели с JavaScript на TypeScript. А бэкенд, написанный на Ruby, трогать не стали. Однако проблемы, связанные с этим бэкендом, заставили разработчиков проекта задуматься о переходе с Ruby на TypeScript. Перевод материала, который мы сегодня публикуем, посвящён рассказу о портировании бэкенда Execute Program с Ruby на TypeScript, и о том, какие проблемы это помогло решить.



Пользуясь Ruby-бэкендом, мы иногда забывали о том, что некое свойство API хранит массив строк, а не простую строку. Иногда мы меняли фрагмент API, обращения к которому выполнялись в разных местах, но забывали обновить код в одном из этих мест. Это — обычные проблемы динамического языка, характерные для любой системы, код которой покрыт тестами не на 100%. (Такое, хотя и реже, происходит и в случае полного покрытия кода тестами.)

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

Фридайвинг — ныряние на глубину без акваланга. Ныряльщик ощущает на себе закон Архимеда: он вытесняет некоторый объём воды, который выталкивает его обратно. Поэтому первые несколько метров даются тяжелее всего, но потом сила давления толщи воды над тобой начинает помогать двигаться глубже. Этот процесс напоминает изучение и погружение в системы типов TypeScript — по мере погружения становится немного легче. Но надо не забыть вовремя вынырнуть.


Фотография с сайта One Ocean One Breath.

Михаил Башуров (saitonakamura) — Senior Frontend Engineer в компании WiseBits, фанат TypeScript и фридайвер-любитель. Аналогии изучения TypeScript и ныряния на глубину не случайны. Михаил расскажет, что такое discriminated unions, как использовать вывод типов, зачем нужна номинальная совместимость и брендирование. Задержите дыхание и погружайтесь.

Делюсь одной из своих библиотек которая называется First DI. Она уже много лет помогает мне решить проблему внедрения зависимостей в браузерных приложениях для таких библиотек как React, Preact, Mithril и другие. При написании First DI за основу была взята идеология DI библиотек языков C# и Java, такие как autofac, java spring autowired, ninject и другие. И точно так как библиотеки из этих языков First DI работает опираясь на рефлексию и интерфейсы Typescript.

Статья описывает трансляцию кода TypeScript в OData запросы во время компиляции программы.

Плагин babel-plugin-ts2odata выполняет разбор JavaScript AST с помощью библиотеки TsToOdata описание которой в моей предыдущей статье Типизированные запросы OData в TypeScript.