Евгений Паромов

Новые начинания!

После возвращения с holy.js я загорелся идеей взаимодействия с людьми. Конструктивный диалог – это очень интересно и полезно для всех слушающих.

И уже в это воскресенье я договорился встретиться с Львом @illright – лидом команды разработки FSD.

У меня много вопросов к FSD 2.1 и тому, куда дальше будет развиваться FSD. А у него есть вопросы по моему докладу на holy.js. Уверен, будет интересно!

Посмотреть стрим можно будет на youtube (https://youtube.com/live/dsIA2py-Oeo?feature=share)
Пройдёт он в 14:00 (GMT+3) в воскресенье 24.11

Можете задавать вопросы в чате. В конце будем отвечать.

А для ребят из моего сообщества будет возможность быть на встрече лично.

В общем, предчувствую классный движ)

Ещё небольшой анонс

Рекламу за деньги я не даю. Только советую ребят, которые мне нравятся или интересны.

Мне недавно написал Андрей Смирнов и попросил поддержать его конференцию по софтам (Soft Weekend), которая пройдёт в эту субботу.

Посмотрел спикеров и увидел много знакомых лиц. Был бы в Москве, сам бы сходил.

Люди часто недооценивают софты, хотя это крайне важно.
Я всегда проходил собесы с первого раза не от того, что знал очень хорошо React (первые полтора года знал так себе, ибо самоучка)

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

Приложил скрин сообщения, с которым ко мне пришли. Лучше создателя о своём детище сложно рассказать)

Новое видео по Next 15

https://youtu.be/BHHUqhySrt0

Думал, как осветить релиз Next 15, и при этом сделать полезный контент.

Решил сделать видео с разработкой с нуля. Так можно и Next.js показать, и раскрыть темы архитектуры и качества кода.

В чём особенность этого видео:
1. Next.js 15; React 19. Использование самых новых функций
2. Реализация моего FSD в контексте Fullstack разработки
3. Использование подобия монады Either для обработки ошибок
4. Чуть чуть RabbitMQ для реализации событий
5. Server Sent Events для риалтайма в next.js

Получилось очень занятно и объёмно

Как вам, вообще, такой формат? Хотите больше разработки с нуля?

За всем этим не рассказал про сам доклад)

Доклад получился хорошим. В основе был 6 урок из курса по FSD про его главные недостатки. Но с важными дополнениями, которые я за год с выпуска курса сформулировал

Всем, с кем общался, понравилось) Но там в принципе все милашки.

Конечно, есть куда развиваться и расти. Нужно больше опыта выступлений именно в живую. Качать дикцию (давно пора) и как я веду себя на сцене.

Но, в любом случае, идею я донёс) Всё получилось достойно. Уже начинаю готовить темы к следующей холи.

Теперь от меня они точно не отделаются ☺️



Кстааати, чуть не забыл. На следующий день после афтепати holy полетел в москву выступать на merge. В 4 лёг, в 11 вылет, в 15 выступление.

С корабля на бал, как говорится. Это конечно не холи, но после доклада очень интересно пообщался с ребятами.

Там был ещё доклад Архитектора из https://zvuk.com/
Они уже 2 года разрабатывают свою архитектуру для фронта. Судя по тому, что мы с ним обсудили, у них получается очень интересное решение, которое собираются выпускать в open source этим летом. Дай бог, выйдет. Всей экосистеме будет от этого сильно лучше

Мне очень понравилось, что там в первую очередь идёт акцент на "примеры и документацию", чего критично сейчас не хватает всем фронтовым архитектурам. В общем, тоже классно пообщались

Всё больше погружаюсь в спикерство, и всё больше это нравится. Посмотрим, как дальше пойдёт)

holy теперь навсегда в моём сердечке ❤️

Ребят, если вы когда-нибудь хотели выступать – выступайте

Это круто! Даже не так. ЭТО ОХЕРЕННО!!!

Я уверен, что для обычного зрителя это тоже классно. Организация на holy идеальная. Спикеры топовые.

Но когда ты становишься спикером, открывается новый мир...

Когда мне говорили слово «нетворкинг», я представлял себе интересные дискуссии с топовыми специалистами.

И да, всё так и было. Это оказались просто топовейшие 2 дня на общение. Которые дали мне кучу мыслей для размышлений

Но потом ты обнаруживаешь себя в 3 часа ночи в баре. Орёшь песни под гитару. Орёшь ПИИИИВО всей толпой, просто потому что это весело. И вот это уже совершенно другой нетворкинг. Тьфу, даже не хочеться этим прагматичным словом марать то, что там происходило. Это было супер душевно
(Кстати, я не пью, но это не мешало мне кайфовать)

Короче, ребят. Словами это не передать. Просто надо попробовать)

Отдельные лучи добра Илье Оловянникову и всему сообществу moscowjs
Просто самые милые люди на свете 🥰

Вообще за holy познакомился с кучей народу и даже договорился на первую коллабу.

Следующий раз, когда буду в Москве, мы с Саней запишем для вас подкаст.

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

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

Короче, holy.js офигенный. Открылось для меня это всё теперь с другой — душевной стороны)

(В комментах пруфы)

Сегодня выступаю на holy.js 🤩

Накануне проехали 1500 км на машине одним днём, отвезли дочку к родителям. Сами полетели в Питер, и вот я тут)

Ощущения следующие:
1. Устал. Последние дни докручивал доклад и прям много сил на этом оставил
2. Здесь совсем другой уровень организации, чем на Стачке. Сразу видно, за что берут такие деньги
3. Я буду выступать на большой сцене. Значит то, что я делаю и говорю, интересно людям. Приятно)
4. Хочется познакомиться и пообщаться с другими спикерами, но пока страшновато... С начала своего блогинга я в определённой изоляции. И сейчас уже дорос технически для коллабораций. Но внутренне как будто ещё что-то меня сдерживает
5. Ребят, если кто на холи и хочет со мной пообщаться – залетайте в дискуссионную зону после доклада. Буду рад увидеть подписчиков)

Что я могу дать этому миру

За последние 2 недели со мной произошли важные вещи.

После 6 лет разработки с акцентом на архитектуру и код. После полугода исследований, сотен часов менторинга и десятков часов обучающих курсов. Я, наконец, достиг того, к чему так долго шёл...

Я смог создать систему

До этого я давал разрозненные знания: как лучше работать с Api, как лучше работать с Redux, как лучше работать с FSD.

Но мне не давала покоя одна мысль: "Хоть я и говорю о разном, но я говорю об одном и том же".

Я начал видеть, что нет разрозненных и противоречивых: SOLID, ООП, ФП, GRASP, FSD, Чистой Архитектуры, DDD, DRY

Есть принципы, которые разными словам говорят об одном 👉🏻 Как писать поддерживаемый код

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

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

Самое важное: учесть и объяснить всё. Почему код на SOLID бывает сложным. Почему код в функциональном программировании надёжнее, чем в ООП. Как можно использовать ООП и ФП вместе. И почему между ними, на самом деле, не так много разницы.

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

Но в виде практического курса «как писать расширяемый код"

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

Уже сейчас в сообществе вам доступен самый базовый и важный курс моей системы:
"Как писать поддерживаемый код", где я в 10 часах практики показываю, как через сочетание принципов OOП ФП GRASP SOLID DRY можно научиться эффективно писать обычный React код.

Всего в курсе будет разобрано 4 главные характеристики поддерживаемого кода:

1. Простота
2. Надёжность
3. Переиспользуемость
4. Абстрактность

Уроки про "Простоту" и "Надёжность" уже готовы. И в ближайшее время я выпущу уроки про "Переиспользуемость" и "Абстрактность"

Что важно: этот курс – не вся моя система. Это скорее самое базовое введение. На основании которого я буду строить дерево знаний.

В отдельных курсах буду рассказывать про SOLID, ООП, ФП, GRASP. Рассказывать, как выбирать технологии на основе этих принципов и учить вас писать инфраструктурный код на сложном typescript

И всё это (на самом деле, намного больше) ребят, за 15к в год. Я намеренно сделал не большую сумму. Чтобы она была доступна всем, но которой мне будет хватать для содержания семьи)

Если хотите научиться писать поддерживаемый код, а не просто узнать "что ООП это про котиков" – вступайте в сообщество @welcome_paromovevg_bot
Всех жду 🤗

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

Сказать, что приятно – ничего не сказать 🤩

Мама, я в телеке)

В продолжение темы конфликтов

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

Как раз в тему конфликтов тут вышел интересный материал с очень "красноречивым примером" про драку 15 монтажников в сибирской тайге 😂 https://t.me/dmiboldyrev/77

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

Нашёл любопытные подтверждения своих наблюдений и даже свой тип личности в "борьбе за статус".

Я из тех, кому больше всех надо, но кого поначалу из-за этого часто считают выскочкой) Теперь, кстати, понятно стало, почему давить в начале так сильно не стоит

Ещё во многом узнал людей, которые не соглашаются даже с железными аргументами, только что бы своим признанием неправоты "не подорвать свой статус". Эти ребята – мои любимые)

В общем, советую вообще весь цикл посмотреть с начала. Тут много крайне профессионального и глубокого – всё, как я люблю 🙂

Nextjs 15

Вышел новый мажор Next.js с, наверное, самым важным для меня изменением с момента релиза AppRouter. А именно –отменой кэширования по умолчанию

Почему это для меня так важно? Потому что это бесконечный источник багов

Есть такое выражение: "В программировании 2 самые большие проблемы – наименование переменных и инвалидация кэша"

И если это звучит, как шутка, то на самом деле это, действительно, 2 самые серьёзные проблемы.

Любой кэш – необходимое зло.

Кэш — это осознанное нарушение DRY, когда мы создаём дублирование состояния для экономии вычислительных ресурсов.

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

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

Кэш – это сложно. Особенно такой кэш, который сделали в Next.js, где он ровным слоем размазан по всему приложению.
Каждый сегмент имеет свой кэш, каждый вызов fetch имеет свой кэш.

Представьте себе обычного разработчика, который начинает осваивать Next.js и просто не понимает, почему у него постоянно показывается старая страница, fetch возвращает старый результат.
После мутации вообще хрен заставишь Next.js показать новые значения. И даже, если ты явно указал, что и как инвалидировать, в какой-то момент инвалидация может не успеть пройти, и пользователь увидит старое значение, которое он только что поменял

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

Но кэш нужен не всегда! А если он нужен, то включать его требуется очень аккуратно и с полным пониманием дела.

А как до этого было с next.js? Бля, опять ничего не работает. Пойду курить и пробовать всякие магические строчки из документации.

Крайне ужасная ситуация. Ребята это тоже поняли и, наконец, исправили

Слава богу, теперь у нас next.js — это просто php)

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

Кто знает, может теперь Next.js не будет вызывать такого отторжения)

Конфликты

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

Но тут важный момент: на пусечках-заечках воду возят

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

У меня в этом месте за время работы произошёл коренной слом.

Я человек, по своей сути, не конфликтный. Раньше я боялся конфликтов, как огня.
Поэтому, когда мне что-то не нравилось:
— давали не интересные задачи,
— оставляли комментарии на CR, с которыми я был не согласен
— принимали в проекте практики и технологии, которые я считал не эффективными
👉🏻 Я просто молчал и терпел.

И кто то скажет: молодец. Командный игрок. Не начинаешь сраться по пустякам.

Но проблема такого подхода в невыраженной агрессии. Она копится.

Вообще, в долгосрочных отношениях в терпилу нельзя играть. Рано или поздно, я просто сваливал или выгорал.

Как раз намного более здорово — пойти в конфликт и начать отстаивать свои интересы. Только так можно занять комфортное для себя положение в команде и не страдать каждый день.

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

После того, как я осознал это, моя позиция по конфликтам поменялась. Я их теперь не боюсь. Не считаю ни агрессию, ни сами конфликты чем-то плохим.

Только крайне важно сраться правильно.

Корректно проведённый конфликт может сделать отношения комфортнее. Производительность команды выше. Текучку команды ниже. (Классический шторминг из модели Такмана)


На основе знаний психологии я вывел следующие правила конструктивных конфликтов:
1. Признавай свои ошибки первее оппонента. И вообще допускай, что ты что-то не знаешь
2. Признавай сильные стороны своего оппонента.
3. Готовься к дискуссиям заранее. Изучи вопрос более тщательно и заготовь основные аргументы
4. Никогда не оскорбляй оппонента и не пытайся унизить его достоинство
5. Помни о цели конфликта. Отстаивай свои интересы, а не пытайся показать, какой ты крутой (Хотя, может это и есть твоя цель 😂)
6. Как можно раньше переводи конфликт из чата в созвон или встречу

Короче, не будьте терпилами и конфликтуйте правильно

Полный курс по react-query ⤵️

https://youtu.be/K5-a-wjURrc

Я очень люблю react-query. Это один из тех инструментов, которые просто хорошо делают свою работу.
И не пытаются собой всё пространство занять.

Помню, как я в своё время наткнулся на этот инструмент. Мне надоело делать одно и то же и писать isLoading, error, data. Сначала написал свой кастомный хук, а после подумал: "неужели никто не решал эту задачу до меня?".

Господи, сколько я сэкономил времени и сил, когда начал делать запросы специализированным инструментом

Но, к сожалению, у react-query есть проблема. В сложных приложениях его сложно использовать правильно.

Часто делают как-то так:

const { data } = useQuery();
useEffect(() => dispatch(setData(data)), [data])

И это самое, что ни на есть жестокое нарушение Single source of truth, которое ведёт к багам и проблемам.

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


Кто уже работал с tanstack — советую сразу по тайм кодам идти ближе к концу, где я показываю интеграцию с redux. Также советую обратить ваше внимание на тайм-коды с пометкой [ВАЖНО]


Приятного просмотра, друзья)

SSG, или как я повернул не туда

Я долго считал SSG манной небесной. Ну сами посудите — большая часть рантайма уже выполнена на этапе сборки. Осталось отдать пользователю статику с небольшими "островками интерактивности".

Получается максимально возможная производительность. Всё это можно раскидать по CDN, и получится прям вах вах.

Но за всё нужно платить...

Так как в моей голове прям плотно сформировалось: если можно сделать SSG, то лучше SSG,
я начал всё прям силком в рамки этого SSG затаскивать.

И тут для настоящего SSG адепта настаёт сложный момент:

— Все переменные окружения должны быть известны на этапе сборки (Теперь Docker image нельзя запустить в разном окружении. Ата-та от девопса)
— Доступ к продовой базе данных должен быть на этапе сборки (А тут уже ата-та от безопасников)
— А что делать с интернационализацией? Получается, что нужно делать сборку под все языки сразу. А как отдать пользователю нужный контент? Появляются всякие прикольные /ru в путях
— Нет возможности использовать заголовки, в том числе, куки на сервере. И это достаточно жёсткое ограничение, которое сильно связывает руки
— Большой гап между изменениями в контенте и тем, что увидят пользователи. + Автоматизация этого процесса – значительно более сложное занятие

Короче, в результате получается какое-то сражение с ветряными мельницами. И я это сражение успешно выигрывал постоянно.

Но какой ценой? Ценой значительного повышения ментальной сложности.

Вот и получается, что установку можно и нужно сформулировать наоборот.

Любой кэш – это сложно (помните 2 самые главные проблемы в программировании)

И любой кэш нужно добавлять после. Когда без него не обойтись.


Короче, это я к чему. Если вы разрабатываете новую приложуху. И у вас не будет мильёнов пользователей с релиза. Забейте на SSG и на кэши

Если пишете на Next.js

const dynamic = 'force-dynamic'

И погнали

Сэкономите время себе и бизнесу.

Но не воспринимайте мои слова буквально. Если вам нужен SSG, то вам нужен SSG. Но важно понимать, что SSG – это сложно

Coolify — Self-hosting с батарейками

Я тут записал видос, который, считаю, нужно посмотреть всем!!
https://youtu.be/XoUF1RstrGw

Рассказываю почему ⬇️

Деплоить свои проекты – это боль.
Либо ты берёшь Vercel + Heroku. Но чуть что, тебе придётся платить не маленькие такие доллары при выходе за бесплатные тарифы (которые не понятно, как им туда отправлять сейчас)

Либо расчехляешь VPS, начинаешь nginx настраивать и возиться с администрированием.
И ладно, если бы получалось хорошо, но вот какой нибудь банальный деплой на пуш уже делается не так просто. А preview deployments сделать уже вообще сложно.

+ Хочется иметь резервное копирование, уведомления, что всё сломалось и так далее.

И сделать это всё на своём VPS – уже проще пристрелиться

Но недавно мне один участник сообщества рассказал про coolify.
Я попробовал и офигел!

Что, если можно совместить удобство Vercel c селф хостингом? 🤯

Оказывается, можно. Coolify – это платформа, которую ты за 5 минут устанавливаешь на сервак, и дальше уже можно деплоить приложения из интерфейса. Быстро, просто и со всеми плюшками:

Деплой на push + preview deployments + health чеки + дампы базы данных – всё из коробки и платить за это не надо. Только за сервак

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

В общем, огонь огнищенский 🔥 Мне даже грустно, что я не знал об этом раньше.

Сколько времени бы сэкономил, и насколько бы лучший DX у меня был

12 часов воркшопов за неделю

Недавно в сообществе появился новый формат — воркшопы.

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

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

Мне и ребятам формат очень зашёл, и я решил сделать целую неделю воркшопов)
Провели голосование и выбрали самые актуальные участникам темы 🔥

👉🏻 В воскресенье мы провели вторую часть воркшопа по билдеру форм.

👉🏻 Вчера был воркшоп по реализации undo redo на redux toolkit на примере аналога trello. И с использованием редкого паттерна event sourcing/

👉🏻 Сегодня (в 19 GMT+3) будет воркшоп по использованию ООП паттернов с Mobx на примере сложного древовидного меню.

👉🏻 А ещё воркшопы будут в четверг и в воскресенье


Кроме воркшопов, в сообществе ещё есть куча курсов и созвонов, в которых можно задать мне вопрос лично (карта контента)


Если хочешь посмотреть на паттерны ООП, залетай уже сейчас 👉🏻 https://paromovevg.ru/evolution-community

Бот для быстрой покупки

Не путайте процветание и выживание

Последнее время много читаю статей про менеджмент и управление.
Вот, например: https://habr.com/ru/articles/816545/
(Кстати, классная статья для анализа своей эффективности — заставила задуматься)

И везде один вопрос: как настолько доказанные неэффективные практики вообще могут существовать?! Ещё и распространяться.

Но для себя я уже давно ответил на это. Мы всегда должны разделять процветание и выживание.
👉🏻 Процветание: Общее количество ресурса
👉🏻 Выживание: Шанс ситуации, когда количество ресурса упадёт ниже условной границы
(Может быть, читал об этом в «Шкура на кону» Талеба. Но уже не помню точно)

Та или иная стратегия может давать очень высокий рост по процветанию. Но вот отбор всегда идёт по выживанию

Вот несколько примеров:
— Максимально распространены не те религии, носители которых счастливы. А те, носители которых лучше выживают и передают религию
— Максимально распространены не те практики, которые дают максимальную прибыль, а те практики, которых достаточно для выживаемости бизнеса, и которые простые (не требуют слома когнитивных искажений)
— Максимально распространены не те практики кода, которые дают максимально быструю и эффективную разработку. А те практики, которые дают достаточную эффективность для выживания бизнеса

И самый мой любимый пример: Смерть

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

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

Представьте: все страдания от смерти родителей, бабушек, друзей, жён и детей — есть необходимое условие выживания человека, как вида

Меня эта мысль до сих пор очень будоражит

Вместо вывода

Весь пост звучит как — смиритесь с говном, оно не избежно.

Но я хочу сказать другое.

Сама суть мира — он не создан для твоего счасться. Только для выживания. И то не твоего лично.

Хватит удивляться дисфункциям вокруг. Возьми ответственность за свою конкретную жизнь. И сделай её счастливой.

Счастье — это не норма. Это то, что ты должен отвоевать у этого мира

Поэтому код в твоём проекте – говно. И это нормально. Хочешь хороший код? Тогда бери и делай. Никому кроме тебя он не нужен.

Все продвинутые курсы в одном месте

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

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

И с появлением сообщества — я вернулся к этой идее.

Теперь весь контент сообщества + все курсы из micro-courses будут вот тут
https://evocomm.space/map

За 15к в год вы получаете уже на нынешнем этапе 50+ часов уникального глубокого и профильного контента.

И с каждой неделей его будет становиться только больше. Дальше он будет всё более полно и системно покрывать темы:

- Архитектуры
- Качества кода
- Эффективного использования инструментов


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

(Целый курс по DRY – это сильно? 😉)

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

И эта карта – только часть всех возможностей, которые вы получаете, вступая в сообещество.

Обо всех штуках можно узнать тут

А вступить в сообщество можно через бота

До встречи в сообществе, сегодня у нас будет вторая часть воркшопа по разработке билдера форм 🙌🏼

Спасибо большое, ребят, за ответы)
52 комментария – это сильно!

Хоть по голосованию React-query и Typescript идут прям вровень, то вот в комментариях однозначно выигрывает react-query, так что с него и начну

Более того, react-query – это одна из моих самых сильных компетенций. Тут мне есть, что сказать 😉

Ждите в ближайшее время новый классный курс с уникальным контентом.