TypeScript *

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

У нас в команде есть пару проектов, для которых есть старые frontend. Написаны все они на разных технологиях, но объединяет их одно: нежелание кого-либо туда лезть и что-то править. Команде там кажется страшно, непонятно и неудобно. Любая доработка превращается в головную боль. В очередном проекте нам хотелось не допустить такого развития событий, и, кажется, у нас получилось.

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

Здравствуйте, уважаемые читатели Хабра!

Как известно, при разработке и ведении проектов, одним из важных моментов является поддержка единого стиля в коде. Зачастую за основу берут какое-то общепризнанное руководство по стилю и дорабатывают его под свои нужды. И если в случае с JavaScript уже есть множество общеизвестных руководств, то с TypeScript дела обстоят несколько иначе. Конечно, если у вас в коде особенности TypeScript используются в мизерной доле, отдельное руководство по нему будет излишним, но если вы хотите использовать TypeScript более серьезно — рекомендации из готового руководства могут оказаться вполне полезными.

В этой статье рассказывается о том, как внедрить аутентификацию в ваш SvelteKit проект. Это будет JWT аутентификация с использованием refresh токенов для дополнительной безопасности. Мы будем использовать Supabase в качестве базы данных (PostgreSQL), но основы должны быть теми же.

С выходом Composition API в Vue появилось новые возможности повторного использования кода. Больше нет необходимости в миксинах, компонентах высшего порядка и прочих “хаках”, если вам нужно вынести общую логику для нескольких компонентов. Но что если у вас есть нереактивный сервис, инкапсулирующий бизнес-логику, а переписывать все на composition api не хочется? 

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

В данном туториале мы разработаем десктопное приложение с помощью Tauri. Tauri — это фреймворк для создания десктопных приложений, похожий на Electron, но позволяющий использовать Rust вместо Node.js, например, для взаимодействия с файловой системой.

В качестве фреймворка для разработки пользовательского интерфейса я буду использовать React и TypeScript, а для работы с зависимостями для JavaScript — Yarn.

Источником вдохновения для меня послужила эта замечательная статья.

Обратите внимание: я буду разрабатывать приложение под Windows x64, в других операционных системах (и архитектурах) детали реализации будут немного отличаться.

Приложение будет представлять собой своего рода однострочный терминал для записи заметок в файл tasks.txt, находящийся в домашней директории (для Windows — это C:\Users\[User]). Приложение будет запускаться с помощью сочетания клавиш Ctrl + Shift + Q и завершаться при нажатии Esc.

Вот как это будет выглядеть:

Репозиторий с кодом проекта.

Если вам это интересно, прошу под кат.

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

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

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

Здравствуйте, меня зовут Дмитрий Карловский и я… крайне плох в построение социальных связей, но чуть менее плох в построении программных. Недавно я подытожил свой восьмилетний опыт реактивного программирования, проведя обстоятельный анализ различных подходов к решению типичных детских болячек:

Main Aspects of Reactivity

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

Статья разбита на главы, перелинкованные с соответствующими аспектами из упомянутого выше анализа. Так что если вдруг потеряетесь — сможете быстро восстановить контекст.

Повествование будет долгим, но если вы продержитесь до конца, то сможете смело идти к начальнику за повышением. Даже если вы сам себе начальник.

Для начала, давайте вспомним, а как вообще ловят ошибки в js, будь то браузер или сервер. В js есть конструкция try...catch. Это общепринятая конструкция и в большинстве языков она есть. Однако, тут есть проблема, и как окажется дальше - не единственная...

Рынок разработчиков прагматичен и суров. Он лишён сентиментальности и далёк от благотворительности. Иначе как объяснить, что он требует от фронтенд-разработчика знать и С, и последние фреймворки? Хорошо это или плохо? Всегда ли так было? Так ли сильно отличается современный фронтендер от себя же в прошлом? Давайте разбираться.

Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. В серии статей мы поэтапно разработаем продвинутое приложение-планировщик. Сначала создадим и настроим монорепозиторий c помощью NX, разработаем интерфейс с помощью React, добавим backend на основе NestJS, и, наконец, подключим базу данных MongoDB.

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

Всем привет :) Хотел бы здесь рассказать о использовании RTK Query + Redux Toolkit в больших проектах, а также ускорить вашу разработку и добавление новых страничек путем избавления от ненужных дублирований кода.

Если ты frontend-разработчик на react, то думаю тебе не впервой сталкиваться с использованием RTK Query вместе с Redux Toolkit, но даже если это так, то думаю мне есть что тебе показать новое ;) А если ты ни разу не сталкивался, то возможно после этой статьи задумаешься об использовании этих библиотечек.

При чтении лучше заглядывать в код проекта, поэтому ссылка. Установка зависимостей: yarn install. Запуск по команде: yarn dev.

Вы когда-нибудь путешествовали по незнакомым местам без туроператора, гида или даже GPS для базовой ориентации в пространстве? Приходится составлять маршрут самостоятельно, разбираться в местности на ходу, импровизировать, чуть ли не рисовать собственную карту… Занятие не из легких, полное трудностей и препятствий, но их решение дарит новые знания и незабываемый опыт.

Решение задачи, поставленной перед нашим сотрудником Артуром Антоновым, напоминало именно такое путешествие, и в этой статье он пройдет его снова с вами.

⚛ О применении слоеной архитектуры в современном React-Mobx приложении

В данной статье я привожу пример использования композиции сервисов через инъекцию зависимостей в React приложении. Это позволяет сочетать проверенный временем подход и проработанные компоненты от Еnterprise и сообщества

Уже больше года мы в Азбуке вкуса мигрируем с jQuery на Nuxt. По мере роста, делали свою реализацию микрофронтов, чтобы хорошо организовать работу и решить ряд проблем.  

В процессе наступили на пару граблей, долго думали и наконец сделали.  

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

Для тестирования гипотез при развитии продукта требуется в короткие сроки реализовать прототип какого-нибудь приложения. В рамках рабочих задач мне довелось поработать над подобным прототипом. Это было backend-приложение предоставляющее RESTfull API и реализованное с применением технологий Nest.js и Swagger. О реализации подобного приложения и поговорим в этой статье.

Все мы знаем про, или слышали про практики и паттерны проектирования SOLID, GRASP, MVC, MV** и даже применяем их с переменным успехом, стараясь нащупать эффективный подход к построению приложений. Но это лишь приводит к разнообразию реализаций наших приложений и частей функционала. Уже долгое время пытаюсь понять по каким правилам должно строиться фронтенд приложение чтобы оно удовлетворяло следующим критериям:

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

Какие у нас есть варианты?

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

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

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

В статье поговорим про одно из таких решений — написание Angular-компонента Slider с помощью встроенных инструментов  браузеров и с минимальным использованием Javascript. Расскажу про доступность, интересное решение с многослойным градиентом, немного CSS-хитростей и даже чуть-чуть про Change Detection в Angular.