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

За всем этим не рассказал про сам доклад) Доклад получился хорошим. В основе был 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 – это одна из моих самых сильных компетенций. Тут мне есть, что сказать 😉 Ждите в ближайшее время новый классный курс с уникальным контентом.

Ребят, хочу записать классный контент на youtube. И передо мной встал выбор, что делать. Долго думал. А потом как вспомнил, что вы у меня есть) Что вам интереснее, проголосуйте плиз ⬇️

Первая в жизни конференция На прошлой неделе съездил на конференцию Стачка в Питере. Сама конференция и выступления максимально мало у меня эмоций вызвали. Ну реально, как будто я 30 минутный видос записывал одним дублем. Единственная разница — живые люди одобрительно кивают, или хихикают над шутками. Это приятно 🙂 Самое интересное было после.. В тот день, когда выступал, у меня было очень холиварное настроение 👿 И любой контакт с другим человеком заканчивался холиваром) Очень долго обсуждали $mol с его автором. Тот момент, когда споришь с человеком, который 7 лет готовился унижать React, а ты даже ни разу не писал на mol. Крайне не выгодная в споре позиция, скажу я вам. На следующий день сходил на его воркшоп, и у меня уже появилось несколько железных аргументов. Но на второй день я уже был лапочка заечка и просто чилился. С самого момента ухода с работы у меня не было отпуска, и это явно чувствовалось. После конференции поехал к родителям, и пару дней провёл на стоге сена, уставившись в небо. Чуть чуть восстановился. Появилось желание продолжать делать интересный контент) К holy.js, которая будет в ноябре, хочу подойти в энергичном расположении духа. Заобщаться там со всеми подряд и привезти несколько интересных колабораций. А пока, возвращаюсь обратно в блог и сообщество с новыми силами и идеями 🙌🏼

Как билдер форм всех спас) В это воскресенье прошёл наш первый воркшоп "Создание форм билдера" в сообществе. Где я показал самый простой и эффективный способ создания этой базовой инфраструктурной штуки. (Такие воркшопы, но по разным темам, будут проходить где-то раз в неделю) А выбрал я эту тему для начала по банальной причине: эта штука может сэкономить месяцы разработки Вот одна показательная история из моего опыта: Нужно было сделать вот такой билдер процессов, как на картинке. Что важно: это была подработка, и я не мог потратить на него слишком много времени. Если сделать карту мне помогла библа (https://github.com/projectstorm/react-diagrams). Кстати, не советую её брать — крайне сложная, хотя и гибкая шо пипец То вот с формами, которые окрываются по клику на каждый блок, встала большая проблема. Их должно было быть 40+ разных штук. Меня вообще не впирало сидеть и делать 40 форм. Плюс я понимал, что эти блоки — точка расширения. И если делать руками формы, то меня будут трясти по этому проекту всю жизнь. И, проанализировав формы, оказалось, что среди них повторяются всего где-то 7 полей. (Текстовые поля, селекты с поиском, редактор условий, массив с другими полями и еще несколько) В общем, я решил сделать, чтобы конфиг форм приходил с бека, а я подготовлю всего 7 полей и уйду в туман. После часов 40 разработки на mui — билдер был готов. Я сделал в storybook, показал бекеру всё и пошёл отдыхать При визуально большой сложности, проект я разработал достаточно быстро. На самом деле, заказчик прифигел от того, как всё неожиданно дешево повернулось. Более того, проект, хоть им активно и пользовались, не требовал правок на фронте где-то год!!! Бекеры просто копипастили конфиги форм и вносили небольшие правки. В моём опыте были ещё случаи, когда простое решение — создать билдер, экономило тонну времени, но это самый показательный пример (Если вам интересны такие штуки — залетайте в сообщество. Через неделю мы проведём вторую часть воркшопа, где подключим форму к беку, обработаем серверные и клиентские ошибки, добавим селект с автокомплитом) 👉🏻 Подробнее о сообществе

Альфа версия Evolution design linter Ещё на прошлой неделе писали, что начали разработку линтера, а вот уже и альфа версия подоспела! Ещё много работы предстоит. Например, написать документацию) Но уже сейчас можно описать с помощью специального DSL архитектуру вашего проекта, и задать основные архитектурные границы и правила. Документации ещё нет, но уже есть пример использования: https://www.youtube.com/watch?v=nU_lFb2LnyM Плюсы бытия ютубера опенсорсера) Особенно интересной получилась реализация генератора. Добавил папочку в pages, и линтер сам сгенерирует нужные папки и файлы с шаблонами внутри. Пример можно в видео посмотреть) Одной из ближайших задач будет написание шаблонов на распространённые архитектуры: — Базовый FSD — Моя версия FSD — Модульная архитектура (великое детище Ульби) Достаточно будет одной команды, чтобы сгенерировать базовую структуру и настроить линтер. Планируем ещё добавить визуализацию архитектуры, ui билдер, и плагины для IDE, чтобы это было полноценным инструментом. Если у вас есть хотелки и пожелания — пишите в комментарии, мы учтём) NPM: https://www.npmjs.com/package/evolution-design GITHUB: https://github.com/ep-community/evolution-design Если хотите помочь нам с разработкой, присоединяйтесь в сообщество: https://paromovevg.ru/evolution-community