Суровый DIY, легаси, kafka и дизайн-система для дам с собачками.

Я не знаю TypeScript, поэтому и пишу эту статью. У меня есть некоторый опыт программирования на Java и PHP и этот опыт заставляет меня кодировать на JavaScript'е соответствующим образом. К последней моей статье коммент от коллеги Silverthorne был такой:

export default class TeqFw_Http2_Back_Server {
constructor(spec) {
// EXTRACT DEPS
/** @type {Function|TeqFw_Http2_Back_Server_Stream.action} */
const process = spec['TeqFw_Http2_Back_Server_Stream$'];
/** @type {TeqFw_Web_Back_Handler_Registry} */
const registryHndl = spec['TeqFw_Web_Back_Handler_Registry$'];

зачем все это, когда есть TypeScript?

В ответном комменте я попросил от него продемонстрировать TS-код, который делает то же самое. Он не ответил. Я добавил коммент с просьбой, чтобы кто-угодно продемонстрировал TS-код, который делает то же самое. Ничего. И вот я пишу уже статью с аналогичной просьбой.

В этом посте будет рассмотрен способ использования mapbox-gl в React приложении, с хранением инстанса карты во вспомогательном объекте обертке. Это позволяет обращаться к карте из любой части приложения, без необходимости передавать ссылку на карту средствами React.

Эта статья — перевод оригинальной статьи Ben Lesh “Learning Observable By Building Observable”.

Ben Lesh рассказывает как создать свой observable и сравнивает его работу с observable из RxJs.

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

Хочу обратить ваше внимание на относительно молодой фреймворк Nest.js. Из коробки он предлагает заранее предопределенную архитектуру, которая заточена под максимально удобную поддержку и масштабируемость вашего приложения. Заложенные архитектурные подходы проверены временем и давно используются в других, более зрелых платформах: Java(Spring), Python(Django), PHP(Laravel) и прочих.

Авторы Nest.js не скрывают, что их вдохновил один из популярных фреймворков для клиентских приложений — Angular.js, а его авторы ориентировались на походы, используемые в Java и C#. Если вы знакомы с Angular.js, то увидите в Nest.js много схожих идей.

Не думаю, что многие разработчики сегодня используют CGI-скрипты и старый добрый PHP. Поэтому у каждого из нас есть любимый фреймворк, с помощью которого мы и создаём свои веб-приложения. Чем бы мы ни занимались — составлением стандартного юридического контракта или съёмками голливудского блокбастера, — всегда полезно начать с какого-нибудь шаблона. Фреймворк придаёт структуру вашему приложению и избавляет вас от необходимости снова и снова изобретать велосипед. Это может быть навороченная платформа — своего рода конструктор, в котором есть всё, что нужно, даже батарейки (Rails, Django, Spring Boot, Nest), — либо минималистичный, но удобный фреймворк, работающий по принципу «тяп-ляп — и готово» (например, Flask или Express).

В начале мая, Misko Hevery, создатель фреймворка Angular, объявил о своем уходе из Google и команды Angular - в компанию builder.io.

Всего через полтора месяца, на его странице в Medium, появился Анонс нового фреймворка - Qwik.

Я решил разобраться, что он из себя представляет и зачем нужен.

Qwik сейчас на стадии proof of concept, и неясно, выстрелит он или нет, но уже понятны основные идеи, и можно потрогать код.

Давайте посмотрим, что интересного он нам принесет, и придется ли нам учить новый фреймворк.

Привет! Меня зовут Андрей, я Backend Node.JS разработчик в одной из зарубежных компаний, занимающихся разработкой системы для администрирования офисов. Наше приложение и его веб-версия предоставляют арендодателям возможность отслеживать заполненность офиса, обеспечивать подключение IoT-устройств для отслеживания, например, количества еды в холодильниках или остатка воды в кулерах, выдавать пропуски для сотрудников в своё здание и много чего другого. Одним из важнейших узлов в этой системе является API как для внутренних пользователей, использующих приложение или веб-сайт, так и для клиентов, использующих наше Whitelabel решение. Всего в нашей системе зарегистрировано более двух сотен API эндпоинтов, для построения которых мы использовали фреймворк NestJS. Если вы по какой-то причины ещё не слышали про Nest, то я настоятельно рекомендую ознакомиться со статьёй NestJS - тот самый, настоящий бэкенд на nodejs. Одной из основных и наиболее значимых особенностей NestJS является нативная поддержка декораторов, что в свою очередь позволяет создавать эндпоинты декларативно.

NestJS - фреймворк, вобравший в себя преимущества TypeScript, IoC/DI и структуру Angular, стремительно развивается, приобретая популярность.

Множество методик и практик описано в официальной документации.

Вдохновившись публикацией John Biundo - Build a NestJS Module for Knex.js, написал свой собственный модуль для Mailchimp Transaction API.

Недавно вышел Angular 12, а вместе с ним в шаблоны подвезли оператор нулевого слияния (??). Но что еще умеют шаблоны Angular, о чем вы, возможно, и не слышали? Давайте разберемся!

Из цикла "Микросервисы или смерть"

Решаемая проблема: монолитное приложение на Node.js раньше, в развернутом состоянии, занимало 0.2 Гб всего. Теперь же, разбитое на 33 микросервиса, занимает 33 * 0.1 = 3.3 Гб. Можно ли избежать подобной издержки? -- можно! В статье мы избавимся от лишнего веса.

В прошлой статье меня упрекнули, что я при живом Vue 3 пишу про "устаревший" Vue 2. Отговорившись тем, что Vue 3 еще не production-ready, я понемногу начал его смотреть и изучать. И поскольку я заядлый любитель типизации и различных фичей с сахарком, то рассматривать Vue 3 с его новеньким CompositionAPI в статье именно с этой точки зрения. А заодно поэкспериментируем и попробуем написать свой типизированный store, организовать компоненты в стиле <script setup> и подружить его с typescript и eslint, а также напишем небольшой компонент на TSX в качестве еще одного эксперимента.

Редакс - Single-store стейт-менеджер, в котором к тому же принято группировать данные по объектам. Примерно так же, как в стейте классовых компонентов в реакте.

То есть, это совершенная противоположность атомарного подхода, которому, к примеру, следуют многие хуки реакта или Multi-store стейт-менеджеры (например Effector, где селекторы не нужны по определению - достаточно сторов).

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

В общем, раз в редаксе нет возможностей ни эффектора, ни MobX, нам лишь остается напрямую обращаться к данным, начиная с самого верха. Это превращается в нечто вроде state.foo.bar.baz. А если перед этим еще нужно произвести какие-то вычисления с участием других значений из стора?

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

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

Мы продолжаем серию публикаций адаптированного и дополненного перевода "Карманной книги по TypeScript".

Другие части:

• Часть 1. Основы
• Часть 2. Типы на каждый день
• Часть 3. Сужение типов
• Часть 4. Подробнее о функциях
• Часть 5. Объектные типы
• Часть 6. Манипуляции с типами
• Часть 7. Классы
• Часть 8. Модули

Обратите внимание: для большого удобства в изучении книга была оформлена в виде прогрессивного веб-приложения.

Определение модуля

В TS, как и в ECMAScript2015, любой файл, содержащий import или export верхнего уровня (глобальный), считается модулем.

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

Модули выполняются в собственной области видимости, а не в глобальной. Это означает, что переменные, функции, классы и т.д., объявленные в модуле, недоступны за пределами модуля до тех пор, пока они в явном виде не будут из него экспортированы. Кроме того, перед использованием экспортированных сущностей, их следует импортировать в соответствующий файл.

Когда веб только зарождался – единственной его целью было размещение контента (гипертекстовые страницы), чтобы у пользователей из всемирной паутины был к нему доступ. В то время не могло идти и речи о дизайне, ведь зачем нужен дизайн страницам с научными публикациями, разве они станут от этого полезнее (первый сайт). Времена меняются и сегодня во всемирной паутине далеко не только научные публикации. Блоги, сервисы, социальные сети и многое, многое другое. Каждый сайт нуждается в своей индивидуальности, ему необходимо заинтересовывать и привлекать пользователей. Даже научные сайты постепенно это понимают, ведь большинство ученых хотят не просто изучать те или иные аспекты, а доносить их до людей, тем самым повышая свою популярность и ценность своих исследований (пример – 15 из 15 научных сайтов списка сделали редизайн в последние 6 лет). Рядовым обывателям не интересен серый сайт с непонятным содержанием. Наука становится доступнее, а сайты преобразуются в приложения с удобным и приятным интерфейсом.

Так как "удобство" у каждого свое – нет четкого определения и конкретных правил по реализации удобного для всех сервиса. В последние годы к этому понятию стали привязывать такое понятие, как Темизация. Именно о нем я и хочу рассказать в данной статье.

Мы продолжаем серию публикаций адаптированного и дополненного перевода "Карманной книги по TypeScript".

Другие части:

• Часть 1. Основы
• Часть 2. Типы на каждый день
• Часть 3. Сужение типов
• Часть 4. Подробнее о функциях
• Часть 5. Объектные типы
• Часть 6. Манипуляции с типами
• Часть 7. Классы
• Часть 8. Модули

Обратите внимание: для большого удобства в изучении книга была оформлена в виде прогрессивного веб-приложения.

Члены класса (class members)

Вот пример самого простого класса — пустого:

class Point {}

Такой класс бесполезен, поэтому давайте добавим ему несколько членов.

Мы продолжаем серию публикаций адаптированного и дополненного перевода "Карманной книги по TypeScript".

Другие части:

• Часть 1. Основы
• Часть 2. Типы на каждый день
• Часть 3. Сужение типов
• Часть 4. Подробнее о функциях
• Часть 5. Объектные типы
• Часть 6. Манипуляции с типами
• Часть 7. Классы
• Часть 8. Модули

Обратите внимание: для большого удобства в изучении книга была оформлена в виде прогрессивного веб-приложения.
Система типов TS позволяет создавать типы на основе других типов.

Простейшей формой таких типов являются дженерики или общие типы (generics). В нашем распоряжении также имеется целый набор операторов типа. Более того, мы можем выражать типы в терминах имеющихся у нас значений.

Дженерики

Создадим функцию identity, которая будет возвращать переданное ей значение:

function identity(arg: number): number {
 return arg
}

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