В процессе написания приложения с более-менее сложной бизнес-логикой на фронтенде возникает необходимость держать всю эту логику на слое предметной области в "толстых" моделях. Например, для работы с формой, которая отображает на пользовательский интерфейс создание или редактирование сущности с большим количеством взаимозависимых свойств. Если "размазать" обработчики изменения состояния этой сущности и входящих в неё подсущностей по слою Application, легко можно потерять целостность модели в разных actions, reducers, валидаторах. Такой код будет трудно читать, отлаживать и поддерживать.

Можно использовать паттерн Aggregate Root для единой точки входа управления моделью, тогда упростится поддержка инварианта такой сущности. Методы доступа к свойствам и методы, меняющие состояние сущности, можно вызывать из одного объекта, а сам объект будет обеспечивать целостность и валидность своих данных. Но здесь появляется ещё одна проблема: сериализация. К примеру, бывает нужно сохранить всю сущность в каком-нибудь хранилище -- localStorage, redux store. Или отправить на бэкэнд для сохранения. Или событием обновить пользовательский интерфейс, а в payload события при этом надо передать часть сущности в виде простого плоского объекта. В этих случаях нам нужна выжимка данных из сущности, которую можно будет восстановить потом при запросе из хранилища для дальнейшей работы. Это особенно актуально, если на проекте используется SSR, там данные, которые собираются для страницы на серверной стороне, должны быть сериализуемыми.

В статье мы рассмотрим, как можно значительно улучшить читаемость кода с помощью двух мощных техник: пайплайнинга (pipelining) и композиции функций (composing). Мы будем использовать TypeScript для демонстрации этих подходов.

Привет, Хабр! Я Саша Пиманов, ведущий iOS-разработчик в МТС Диджитал. Сегодня хочу поделиться подборкой книг для кодеров, которые только начинают свой путь в ИТ-отрасли. Если у вас есть любимые книги по JS, о которых я не упомянул, пишите о них в комментариях. Возможно, заберу их в следующий пост. Ну, поехали!

В статье "Contemporary Front-end Architectures" рассмотрены архитектуры фронт-энда с точки зрения потоков данных в исторической ретроспективе.

Материал состоит из трех частей

1. Теория и история
2. Реализация

3. Перспективы

В этом посте мы вкратце рассмотрим предложение в стандарт ECMAScript «Record & Tuple» от Робина Рикарда и Рика Баттона. Это предложение добавляет два вида составных примитивных значений в JavaScript:

• записи (records) — неизменяемая и сравниваемая по значению версия простых объектов;
• кортежи (tuples) — неизменяемая и сравниваемая по значению версия массивов.

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

Сегодня мы по шагам расскажем, как подключить проверку пользовательских данных с помощью одноразового пароля по SMS. Для этого будем использовать платформу MTC Exolve и фреймворк Flask. Такой метод легко внедрить в свой проект и сделать работу с простыми личными кабинетами удобной и максимально ненапряжной для пользователей.

Логирование во фронтенд-приложениях. Опыт Звука 

Всем привет! На связи Роман Савельев, фронтенд-разработчик в команде Звука. В этой статье я хочу поделиться опытом и рассказать, как мы с командой прошли путь от хаоса до выстроенной инфраструктуры и унифицировали работу с логами в собственных веб-сервисах. Я расскажу, с какими проблемами мы столкнулись, как их решали и какие вывели в best practices. 

Кстати, в best practices даны ответы на вопросы «зачем», «как» и «что» логировать.

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

Многие разработчики, когда дело заходит о стандартном веб функционале, например: хранение boolean значений, отлавливания нажатия клавиш или создания stepper, часто идут гуглить как сделать ту или иную функцию и чаще находят способ с реализацией функционала с полного нуля.

Docker и Kubernetes — два инструмента, которые прочно вошли в арсенал современных разработчиков. Хотите разобраться в основах контейнеризации и оркестрации? Наша статья поможет вам в этом, раскрывая ключевые концепции и принципы работы этих технологий.

Отправляем запрос на 20 000 000 евро, на перестановку 900 ордеров на бирже. Что может пойти не так? 

Сегодня я расскажу, как не терять пару миллиардов клиентских денег, когда уж очень нужно что-то массово сделать на бирже. Этот текст про неявную и, казалось бы, незаметную проблему, которая ждет нас в недрах работы с любыми запросами, которые могут исполниться не до конца – в частности, с HTTP-запросами. Удивительно, как мало об этой проблеме думают и насколько мало инструментов для её решения. 

Задача была такова – реализовать массовое управления биржевыми ордерами, причём не только в рамках одной биржи, а в целом по всей планете. И чтобы оно точно отработало. 

В повествовании будут клиенты, серверы и котики. С котиками всегда интереснее.

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

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

Сегодня мы рассмотрим методы формализации требований: Use Case и User Story. В статье рассмотрим оба метода, сравним их преимущества и недостатки. А также рассмотрим, когда и при каких ситуациях использовать каждый из методов.

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

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

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