TypeScript *

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

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-ов и прочие приятные мелочи.

Предыстория