TypeScript *

Старожилы, наверное, и не вспомнят, но в конце 2017-го года в обсуждениях в интернете была распространена мысль о том, что в трендах YouTube часто встречаются «накрученные» видео.

Поэтому накануне нового 2018-го года я написал утилиту для сбора информации о видео, которые попали в тренды. Для каждого видео запрашивается название, список тегов, дата создания, а так же ведется история изменений лаков/дизлайков/просмотров. Разработку вел на TypeScript для NodeJS, сам код выложен на GitHub.

Как итог, сейчас есть возможность строить красивые графики:

Так же есть возможность строить графики изменения трендов по ключевым словам. Всего за 2018-й год была собрана информация по 29271 видео. Сбор статистики ведется и сейчас.

Давно, в 2014 году я сделал для себя небольшую утилитку, чтобы перегонять C#-вьюмодели в TypeScript-код. Она сэкономила мне немало времени и нервов. И вот, в сентябре 2015 я решил оформить свои "эксперименты на коленке" в некую удобоваримую форму и вылить их на GitHub. Так началось моё дилетантское участие в разработке открытого ПО. Время шло. И вот, вчера в репозитории с этим проектом, наконец, появился юбилейный, трёхсотый коммит. В связи с этим знаменательным событием, я бы хотел поделиться своим дилетантским опытом о том, с чем придётся столкнуться, если вам вдруг взбредёт в голову разработать что-то "на благо развития индустрии". Я изложу некоторые цифры, расскажу несколько прохладных историй, а так же поделюсь впечатлениями каково это — написать и поддерживать opensource-проект без мам, пап и кредитов поддержки компании, оплаты и… и свободного времени. Заходите под кат, присаживайтесь, мы начинаем.

У TypeScript есть встроенная поддержка JSX синтаксиса и компилятор TypeScript'а предоставляет годные инструменты по настройке процесса компиляции JSX. По сути, это создает возможность писать типизированный DSL используя JSX. В этой статье речь пойдет именно про это — как написать DSL из г с помощью JSX. Заинтересовавшихся прошу под кат.

Довелось мне как-то после нескольких проектов на React поработать над приложением под Angular 2. Прямо скажем, не впечатлило. Но один момент запомнился — управление логикой и состоянием приложения с помощью Dependency Injection. И я задался вопросом, удобно ли управлять состоянием в React используя DDD, многослойную архитектуру, и внедрение зависимостей?

Если интересно, как это сделать, а главное, зачем — добро пожаловать под кат!

Давайте пофантазируем на тему функциональной композиции, а так же проясним смысл оператора композиции/пайплайна.

TL;DR
Compose functions like a boss:

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

В данной статье мы рассмотрим:

1. Внедрение зависимостей (dependency injection);
2. Старый способ внедрения зависимостей в Angular (providers: []);
3. Новый способ внедрения зависимостей в Angular (providedIn: 'root' | SomeModule);
4. Сценарии использования provideIn;
5. Рекомендации по использованию нового синтаксиса в приложениях;
6. Подведем итоги.

В настоящее время разработка любого современного фронтэнд-приложения сложнее уровня hello world, над которым работает команда (состав которой периодически меняется), выдвигает высокие требования к качеству кодовой базы. Чтобы поддерживать уровень качества кода на должном уровне, мы во фронтэнд-команде #gostgroup идём в ногу со временем и не боимся применять современные технологии, которые показывают свою практическую пользу в проектах компаний самого разного масштаба.

Все мы давным давно хотим нормальную инкапсуляцию в JS, которую можно было бы использовать без лишних телодвижений. А ещё мы хотим удобные конструкции для объявления свойств класса. И, напоследок, мы хотим что бы все эти фичи в языке появились так, что бы не сломать уже существующие приложения.

Казалось бы, вот оно счастье: class-fields-proposal, который спустя долгие годы мучений коммитета tc39 таки добрался до stage 3 и даже получил реализацию в хроме.

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

Преамбула

В первую очередь, данная статья расcчитана та тех читателей, которые уже знакомы с GraphQL и больше повествует о тонкостях и нюансах работы с ним. Тем не менее, я надеюсь, что она пригодится и новичкам.

GraphQL замечательный инструмент. Думаю, о его преимуществах уже знают и понимают многие. Тем не менее, есть некоторые нюансы, которые следует знать, когда вы строите свои API на основе GraphQL.

Например, GraphQL позволяет возвращать потребителю (пользователю или программе) запросившем данные только ту их часть, в которой этот потребитель заинтересован. Тем не менее, при построении сервера довольно легко совершить оплошность, которая приводит к тому, что внутри сервера (который может быть, в том числе, — распределенным) данные будут курсировать полными "пачками". В первую очередь это связано с тем, что "из коробки" сам GraphQL не предоставляет удобных инструментов для разбора входящего запроса, а те интерфейсы, которые в нем заложены недостаточно документированы.

• Predictable data flow;
• Поддержка OnPush by design;
• Неизменяемость данных, отсутствие накопленных side effect-ов и прочие приятные мелочи.