TypeScript *

Около десяти лет назад сообщество веб-разработчиков впервые начало обсуждать концепцию "Single-Page Application" и искать способы ее реализации. К тому моменту разработка графических интерфейсов уже не являлась чем-то новым и поэтому многие вещи заимствовались у существующих решений и немного адаптировались под специфику браузеров.

Наиболее успешным результатом подобной работы оказался Backbone.js — объектно-ориентированный MVC-фреймворк, который в свое время использовался в BitBucket, Basecamp, Stripe, Airbnb и Trello. Со временем он был полностью вытеснен следующим поколением фреймворков, но...

Что если бы этого не случилось? Как бы тогда выглядела современная разработка веб-интерфейсов?

Недавно Бхарат Рави опубликовал статью о директиве самосохраняющегося select-элемента на InDepth. Это интересная концепция изолирования логики в директиве, что в целом идея хорошая.

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

Чтобы использовать Angular CLI на полную, разработчики должны знать, что такое схематики. Например, команды ng add, ng update и ng generate используют схематики для добавления, обновления и настройки библиотек и кодогенерации в приложениях. Во время выполнения схематика вы получаете доступ к файловой системе и можете мутировать исходный код приложения так, как вам нужно. «Но, чтобы мутировать код, нужно работать с AST, а это сложно», — возможно, скажете вы, и будете правы!

В этой статье расскажу, как мы пытаемся упростить работу с AST и сделать написание схематиков обыденным. А еще покажу, что так же просто можно работать с AST не только в Angular-проектах, а практически в любом проекте на JavaScript/TypeScript.

Вы когда-нибудь работали над несколькими проектами и хотели иметь набор настраиваемых компонентов, которые можно было бы использовать во всех из них? Будь то работа или просто побочные проекты, набор компонентов, к которым вы можете обратиться, - отличный способ ускорить работу в новом или существующем проекте. Но что, если не все ваши проекты используют одну и ту же структуру пользовательского интерфейса? Или, что, если у вас есть тот, который вообще не использует какой-либо фреймворк JavaScript и полностью отрисован на сервере?

Как разработчик Vue, в идеале мы хотели бы просто использовать наш фреймворк для создания сложных пользовательских интерфейсов. Но иногда мы оказываемся в описанной выше ситуации, работая с другим фреймворком JavaScript, таким как React или Angular, или используя внутреннюю систему рендеринга, такую как Rails или Laravel. Как мы можем создать многоразовый пользовательский интерфейс для различных вариантов внешнего интерфейса?

В Vue 3.2 у нас теперь есть решение этой проблемы: веб-компоненты на базе Vue!

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

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

В Angular есть два режима change detection: Default и OnPush. В этой статье мы разберем, как можно спокойно использовать OnPush всегда без лишнего труда и почему стоит начать это делать.

TypeScript Native (AOT) Compiler

Имплементация нативного Ahead-of-Time компилятора для языка TypeScript

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

Привет! Меня зовут Никита. Я разработчик Taiga UI, библиотеки Angular-компонентов, которая активно используется в нашей компании «Тинькофф». Я расскажу про решение одной из таких рутинных задач на нашем проекте с помощью написания с нуля своего Github App на Node.js.

Несколько месяцев назад я написал статью «Как мы делаем базовые компоненты в Taiga UI более гибкими: концепция контроллеров компонента в Angular». Я рассказал о том, как мы добавляем гибкости и избавляемся от дублирования кода с помощью DI. Пришло время продолжить статью.

Сегодня посмотрим на более хитрые трюки с такими директивами-контроллерами и попробуем сделать метаконтроллер, который, в свою очередь, состоит из других контроллеров. Все это будет происходить в рамках безграничных возможностей Dependency Injection в Angular.

Первое, что нужно понять об операторах, - это почему они существуют. Они существуют, потому что observables как тип позволяют нам обрабатывать события (или значения во времени) как множества или набор вещей.

Говоря более просто, любое четко определенное множество будет иметь операции, которые могут быть выполнены с ним, которые могут преобразовать его в новое множество того же типа. Например, предположим, что у нас есть грузовик с яблоками. Мы могли бы превратить его в грузовик с нарезанными яблоками с помощью машины для нарезки яблок. Та же самая машина для нарезки яблок затем может быть использована на любом грузовике с яблоками, чтобы превратить их в грузовик, загруженный нарезанными яблоками. В этом случае машина для нарезки яблок будет считаться «оператором», который сопоставляет яблоки с ломтиками яблок. Точно так же мы могли бы иметь грузовик с сахаром, мукой, яйцами и т. д. И объединить их с грузовиком с ломтиками яблока, чтобы сделать грузовик с яблочными пирогами, используя какую-то машину для производства пирогов. Итак, в этом примере грузовик - это тип множества, машина для нарезки яблок или машина для изготовления пирогов будут «операторами», а сахар, яблоки, ломтики яблок, яйца и т. д. Будут просто значениями, переносимыми нашим типом множества.

Давайте на секундочку представим, что будет если объединить React-компоненты и дженерики...

Относительно недавно мы начали строить качественно новую версию платформы "Юнидата", в которой изменилось очень многое, включая архитектуру, технологии, подход. Даже основная идея продукта приросла новыми деталями.

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

Об авторе статьи. Меня зовут Илья, я занимаюсь разработкой новой версии. Мне не довелось работать с предыдущими версиями "Юнидата", и в проект я пришел на этапе прототипа. Я могу быть не до конца объективен на тему того, почему было выбрано то или иное решение, если это происходило еще до моего присоединения к продукту. В причинах перехода я написал свое видение, после общения с командой.

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

Краткий тех.обзор

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

Кроме того, продукт разделён на Community Edition (хранится в публичном гитлабе) и Enterprise Edition.

Фронтенд состоит из 20 модулей (число не конечное). Мы используем свежую версию typescript и почти свежую react (сейчас 16, но перевод на 17 - дело ближайшего времени). Применяем MVC подход в каждом модуле: реакт только view-слой, своя observable модель (обязательно про нее напишем отдельную статью), mobx сторы в качестве контроллеров.

Frontend-разработка и разработка вообще — это не только код и экран, но и предметы генеративного искусства, которые можно сделать принтом или перенести на настоящие холсты, повесить на стену вашей комнаты и, переводя взгляд с монитора, наслаждаться приятной глазу абстракцией.

Мы уже писали о полях течений, а сегодня, к старту курса о визуальной части веб-разработки, делимся переводом статьи, где вы найдёте генератор абстрактных картин как на КДПВ и, конечно же, его код.

И снова привет — год назад я написал на Хабр о своём клиенте для этой площадки, который я разрабатывал в качестве проекта для оттачивания навыков программирования. Теперь мой Хабр посетило больше 30 тысяч человек, а я за прошедший год полностью обновил дизайн, прикрутил авторизацию, увеличил скорость приложения и оптимизировал клиент для разных viewport'ов.

Попробовать кастомный клиент можно по этой ссылке — geekr.vercel.app, а если интересно, как я такую вещь сделал и что планируется сделать в будущем, то прошу под кат.

О чем эта статья?

1. uWebsockets.js - высокопроизводительная реализация http/websocket сервера для nodejs

2. AsyncAPI - спецификация для асинхронного API, с помощью которой можно создать описание Websocket API

3. Простой пример websocket API с использованием библиотеки wsapix:
- создадим websocket сервер, используя uWebsockets.js
- настроим валидацию получаемых и отправляемых сообщений
- добавим генерацию документации из кода

Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето:
- 20% времени мы пишем новый код.
- 80% времени поддерживаем старый. Поддержка в себя включает фиксы багов, обновление кодовой базы (переезд на новые библиотеки например).

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

Примерно год назад фронтенд нашего проекта, в качестве фреймворка для которого используется Vue.js 2, дошел до состояния, хорошо описываемого словами "проще сжечь".

К тому времени наш нетипизированный корабль уже трещал по всем швам, и решено было убить сразу нескольких зайцев одним выстрелом: полностью перевести проект на TypeScript, внедрить Vue Composition API и решить проблемы валидации сложных форм.

А проблемы были. Vuelidate - отличная библиотека с массой готовых валидаторов и остается таковой до тех пор, пока мы имеем дело с, так сказать, плоскими формами - формами, не использующими вложенных компонентов, также требующих валидации. Vuelidate работает на уровне компонента, требует наличия миксина, содержит массу правил, которые нам не были нужны, но все равно тянулись в составе пакета, поддержка TypeScript и Composition API на тот момент отсутствовала, и мы не могли более с этим миритьcя.

Проекция контента — одна из базовых возможностей Angular, о которой слышали почти все. А с недавних пор по ней появилась и хорошая официальная документация. Тем не менее в реальных задачах разработчики часто обходят ng-content стороной, прибегая к более сложным и перегруженным решениям и усложняя дальнейшее использование и поддержку компонента.

В этой статье я хотел бы показать несколько типовых кейсов для ng-content при разработке многократно используемых компонентов. А еще — рассказать о преимуществах, которые они могут нам дать.

Приветствую всех читателей Хабра.

Немного разбросал текущие дела и пришло время для написания следующего поста в моем запланированном цикле статей:

Привет, Хабр! Несколько месяцев назад Wrike публично объявил об отказе дальнейшей разработки на Dart и переходе на новый стек.

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

В этом тексте мы подведем итоги панельной дискуссии в виде небольшого конспекта: тезисно и с цитатами. Полную видеозапись встречи вы найдете в конце статьи.