TypeScript *

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

• MarkedText — стройный легковесный язык разметки текста (убийца MarkDown).
• Tree — структурированный формат представления данных (убийца JSON и XML).

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

 TL;DR: игра по ссылке.

Наверняка многие из вас в детстве баловались игрушками вроде «ПРОГРАММИСТ 1.3» — эдакими текстовыми квестами, в которых игрок должен был прокачаться из начинающего программиста хакером (термина «сеньор» тогда, наверное, еще не было), собрать самый крутой комп, заработать больше всех денег. При этом весь геймплей заключался в нажатии нужных кнопок действий и менеджменте немногочисленных ресурсов. Я, с теплом вспоминая такие игры, а также текстовые квесты в Космических Рейнджерах 2, решил создать игру Teamlead Simulator, в которой...

Frontend сейчас сильно разрастается, всё больше компаний переписывают свои старые решения на SPA. В компании которой я работаю это не обошло стороной.

По умолчанию был выбран фреймворк Nuxt.js, т.к Vue лучше React :))
В общем суть не в фреймворке, а с чего начинаем.

NestJS прекрасный фреймворк под Node.js, вдохновлённый серьёзными фреймворками Spring, ASP.NET Core, Simfony.

Так что же там внутри прекрасного и ужасного?

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

Особо впечатлительным просьба смотреть через розовые очки.

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

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

Всем привет, не так давно ко мне в команду в ПРОФИ пришла задача реализации довольно комплексной в плане верстки и интерактивности карты, на которой бы отображались заказы, оставленные нашими клиентами. Мы решили использовать фреймворк, адаптирующий яндексовый SDK под реакт.

react-yandex-maps + доки к нему

UI маркеров почти полностью приходится настраивать по докам уже Яндекса, тк react-yandex-maps предоставляет нам только внешний интерфейс, позволяющий довольно удобно прокинуть параметры в объект маркера как пропсы.

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

Решили in-house разработать CRM систему. По ходу разработки встречались интересные моменты, которые постараюсь описать в нескольких статьях. В статьях постараюсь избежать банальностей типа: скачал, распаковал, запустил, и вот глядите, swagger из коробки. Таких статей, как и видео на Ютубах, уже очень много. Постараюсь поделиться просто интересными деталями, которые встречались по ходу разработки. Забегу вперед — систему настроили и запустили.

⚛ Проектируем DataGrid на React так, чтобы сэкономить Boilerplate

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

⚛ Джентльменский набор React компонентов FullStack разработчика для управления потоком данных.

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

При создании react-приложений часто появляется необходимость расширить функционал уже существующего компонента или переиспользовать общий кусок логики между компонентами, желательно минимально не вмешиваясь в реализацию целевого компонента. У большинства разработчиков в таком случае мысль в первую очередь обращается к использованию HOC (hight order component или по-русски компонент высшего порядка) или же кастомных хуков. Однако у меня нет никакого желания пересказывать вам уже всем давно известные паттерны, которые вы, вероятно, знаете даже лучше меня.

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

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

Хотя автомат из 100500 стейтов с вложенными и параллельным стейтами, пожалуй, будет слабо читаемым. Но это уже тема для Separation of Concerns - разделения ответственности.

В этой статье я хочу рассмотреть замечательный инструмент XState.

Который позволяет как описывать эти автоматы, так и рисовать в редакторе и визуализировать.

Привет. Недавно вышла первая стабильная версия 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 реализацию, вобравшую в себя все самые крутые идеи, позволяющие достигнуть беспрецедентной выразительности, компактности, скорости, надёжности, простоты, гибкости, экономности..

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

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