История вопроса

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

Мне уже давно и прочно нравится мир Vue. Особенно завораживает скорость, с которой в нём рождаются новые возможности писать код более лёгким и понятным. Недавно появились Composition API, VueUse, Vite… По ходу освоения этих новых инструментов я нашёл шаблон Vitesse, буквально насыщенный удобными средствами — и для управления макетами (layout), и для маршрутизации, и для локализации и ещё для много чего… Возможно, есть смысл написать отдельный обзор этого арсенала по русски (чего в Интернете пока ещё нет). Но сейчас речь не об этом.

Я написал интернет-магазин для магазинов мяса на Blazor Server(это не WebAssembly). Там фактически нет фронта, есть только бекенд. Всё события и изменения в DOM-дереве передаются на сервер через WebSocket и сервер генерирует новый html и шлет обратно. То есть onclick можно обработать прямо из C# и там же скачать, к примеру данные из базы. Это очень удобно, никаких проблем с HTTP запросами! Blazor абстрагирует меня от этого. Кстати, в React 17 появилась така штука как React Server Components, это чисто копия подхода Blazor. Теперь можно написать компонент и с него же обращаться, в базу, например.

Но, поначалу все было очень классно и удобно, что позволило мне быстрее написать интернет-магазин, но потом возникли проблемы.

В некоторых случаях хук — это обычный хук, но часто вам понадобится больше контекста. Эта короткая статья в блоге обобщает сказанное. Пользовательские React хуки — это очень удобный способ инкапсуляции логики и передачи данных вниз по дереву рендеринга. 

Правила для пользовательских React хуков довольно просты:

Пользовательский хук — это функция JavaScript, имя которой начинается с "use" и которая может вызывать другие хуки.

Привет, друзья!

В данной статье я хочу рассказать вам об Internationalization API — интерфейсе, предоставляемом браузером, позволяющем выполнять интернационализацию и локализацию веб-приложений.

Статья состоит из 2 частей: теоретической и практической. В теоретической части мы кратко рассмотрим возможности, предоставляемые Internationalization API. В практической — создадим пример локализованного приложения с помощью разработанной мной утилиты.

Шаг 1. Установка NextJS

yarn create next-app

Шаг 2. Установка пакетов:

yarn add express redis node-gzip

Шаг 3. Создаем в  корне проекта файл server.js

Привет! Меня зовут Данила, и я фронтенд-разработчик в KTS.

Однажды в одном из своих проектов мне потребовалось реализовать кастомный текстовый редактор на React.js. Задача показалась мне довольно интересной, и я решил рассказать о своем опыте. В статье я поэтапно покажу, как можно создать текстовый редактор с базовыми функциями.

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

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

Если вы рассматриваете запросы на исправление или создаете программное обеспечение в команде, пользовательские правила eslint могут сэкономить вам много времени. Вот как это делается.

На Хабре есть уже множество статей об крутой библиотеке TensorFlow.js, но я так и не смог найти что-то об ml5.js - это как TensorFlow, только здесь не надо заботиться об нижних уровнях нейросети. К слову ml5.js не хуже TensorFlow, просто эта библиотека уже больше подходит для каких-то упрощенных проектов где не требуется внедрять нейронную сеть с контролем например: тензоров или оптимизитаров. Да и сама библиотека ещё хорошо подойдет для тех кто ещё свой путь в машинном обучении.

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

На сегодняшний день существует несколько тысяч языков программирования, каждый из которых создавался с определенной целью, пытаясь изменить и улучшить недостатки своих предшественников. Так, например, появился язык Kotlin, который был нацелен на замену Java в мобильной разработке. В 2010 году увидел свет язык Rust, разработчики которого пытались создать быстрый и безопасный язык, который закрывал бы многие недостатки C/C++.

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

Но как объединить несколько разных языков в одном приложение, чтоб это работало?

Новое это давно забытое старое...

История о том как случайно получилось найти супер способ передать параметры в независимый javascript виджет.

GET параметры? Нет кое-что получше.

Доброго времени суток, коллеги. Эта первая статья (вводная), далее будут подробные статьи по каждому из пакетов кастомных HTML элементов и веб-компонент. Разрабатывая веб интерфейсы на протяжении многих лет, мы заметили что веб разработка с каждым годом становится все сложнее и сложнее. В современных веб приложениях, императивный JavaScript занимает чуть ли не 100% всей кодовой базы, а декларативный HTML может вообще отсутствовать как таковой. Этот факт превращает любой такой веб проект в неподдерживаемого монстра всего за год-другой. Мы очень долго жили с этой болью и вот, наконец, мы решили это изменить, сделав нечто настолько простое и удобное, что способно в корне изменить разработку современных веб приложений. Хочется сказать, что данная статья и сам UiWebKit будут полезны преимущественно прогрессивным веб разработчикам, так что будьте готовы к нестандартным идеям.

Работаю с в строительной компании в проектном отделе. Занимаемся проектированием металлических конструкций. Заказчик передает документацию, которую проектировщики должны превратить в BIM модель. Зачастую в документации Заказчика встречаются несостыковки между отдельными разделами, внутренними стандартами проекта или ГОСТами. В таких случаях пишется технический запрос (technical query) с каким-либо предложением, чтобы конструкция была в соответствии с другими разделами или удовлетворяла стандартам. Написание таких запросов является одной из моих обязанностей. Процесс этот несложный, но жутко рутинный. Ниже схема пайплана этого процесса.

Всем доброго времени суток!

Сегодня речь пойдёт о таком страшном звере, как micro-frontend. Знаю: всем эта тема порядком надоела, но просмотрев полтора десятка выступлений осознал, что не все до конца понимают, что это такое и какие сложности следует решать при организации micro-frontend’а. В данной статье я дам универсальные советы, расскажу с чем не стоит связываться и, в целом, как не превратить проект в ад из callback’ов или непонятных интерфейсов. Итак, обо всем по порядку.

Что такое micro-frontend?

Точного определения днём с огнём не сыщешь. Суть в том, что термин micro-frontend подразумевает наличие множества изолированных приложений с интерфейсом, для взаимодействия с ними посредством API. Это позволяет использовать версионированность, не опираясь на рядом стоящие компоненты. Наглядным примером такой реализации являются различные npm-пакеты. Так же micro-frontend подразумевает под собой использование микро-сервисной архитектуры, что в совокупности даёт нам инкапсулированную логику не зависящую от окружения.

Чем был плох предыдущий подход - монолит?

Для того, чтобы понять преимущества micro-frontend’а нам следует разобраться чем именно он отличается от, так называемого, монолита.

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

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

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

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

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

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

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

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

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

Всем привет!

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

Привет, Хабр! Команда ВТБ Лизинга хотела бы поделиться историей о том, как мы начали выстраивать новый IT-ландшафт для системы электронного лизинга автомобилей. Эта система не имеет отношения к знаменитой программе-собеседнику, просто название “e-Leasing” как-то естественно превратилось в Элизу, да так и прижилось.

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