Еб*ная веб версия telegram

Я вам тут сейчас только что написал охрененный пост про ArkType 2 и про type level программирование.
Про то, что он с помощью сложных typescript типов парсит строковые литералы в AST дерево и потом выводит в тип схемы.

За счёт этого получается ооочень удобный лаконичный синтаксис. При этом скорость работы такого решения выше, чем в zod, почти в 100 раз. Отчасти, так как нет оверхеда на лишние вызовы.

Писал про то, что есть тренд на такие typescript first решения. Где за счёт typescript сильно уменьшается размер бандла и увеличивается скорость работы, при сохранении удобства и автодополнения.

Посмотрите на trpc / openapi-fetch / drizzle – это всё решения, которые находятся в этом тренде.


А потом, когда я нажал enter, чтобы отправить этот пост в сохранённые сообщения, он просто не сохранился.

Да, он получился достаточно длинный. Но бл*ть. Кто просто молча стирает то, что я с таким трудом и энтузиазмом писал 40 минут!!!

Слов моих нет. Грёбаное useEffect программирование. Я знаю, что это он. Это так похоже на очередной баг из-за не вовремя сработавшего эффекта. Я ведь знаю, что этот web клиент написан на react. И знаю, что он написан ужасно.

Господи, пожалуйста, друзья. Перестаньте писать эти сраные useEffect.
Если вы хотите научиться, у меня в сообществе есть 4х часовой воркшоп и 8 паттернов из курса «58 реакт паттернов» специально рассказывающих, как писать без useEffect.

Пожалуйста, перестаньте писать useEffect. Давайте бороться с глобальным потеплением от постоянно горящих пердаков пользователей приложений на React. (Всяким адептам vue молчать. watchEffect такая же хрень)

Typescript, который никто не знает

Когда я начинал учить typescript, мне он показался очень простым. Типы параметров описываешь и всё.

Но как только выходишь за порог hello world примеров, начинаются сложности:
– непонятные громоздкие ошибки
– библиотеки, которые возвращают unknown
– сраный useRef, в который ты обязан указать точный тип HTML элемента, и других вариантов нет

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

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

Но я был всегда из другого лагеря. Из лагеря тех, кто любит написать удобную красивую инфраструктуру.
Я начал это делать ещё когда писал js код. И там это было супер просто. Динамичность js позволяет делать очень весёлые штуки.

Но потом, когда я перешёл на ts, я опешил...

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

А когда начинаешь смотреть примеры готовых решений, глаза начинают на лоб лезть🤯

type OnlyStringKeys<T> = {
 [K in keyof T ]: T[K] extends string ? K : never
}[keyof T]

function sortByKey<T>(arr: T[], key: OnlyStringKeys<T>){
 return [...arr].sort((a,b) => {
  const v = a[key] as string;
  const v2 = b[key] as string;
  return v.localeCompare(v2)
 })
}

В этот момент я понял. На самом деле, typescript не такой простой, как кажется. У ts есть второе дно – type level программирование

Так как ts должен был типизировать все сложные штуки, которые авторы js билиотек наворотили, ему пришлось стать языком с мощнейшими инструментами манипуляции типов. Чтобы иметь возможность выразить практически всё!

Написать калькулятор на typescript типах? Пожалуйста
Написать wordle? Пожалуйста

На самом деле, система типов typescript полная по тьюрингу

Вы до сих пор думаете, что знаете typescript? Я тоже, на самом деле, не знаю.

Но я хочу поделиться с вами всеми знаниями и опытом, которые я собрал за 5 лет о typescript.

К сожалению, эти знания не лежали на поверхности. Доку прочитать не достаточно – нужно знать ограничения, паттерны, практические приёмы. Нужно научиться мыслить type level программированием.

И поэтому сегодня в сообществе выйдут первые уроки курса: Продвинутый typescript.

В процессе изучения которого мы тщательно изучим систему типов typescript и напишем копии:
zod, @reduxjs/tooklit, react-hook-form, trcp. И, конечно же, напишем калькулятор на typescript типах. (это же весело)

После этого курса typescript перестанет для вас быть преградой и неудобством. А станет для вас любимым инструментом для создания топового developer experience

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

Всем typescript! Настало время узнать свой основной инструмент)

Легенда, там твой доклад выложили https://youtu.be/yRH0O4Fn53U?si=S6j1irub8EZGCdwN

Зачем нужен сложный typescript?

Пока в сообществе выходит курс по typescript, в котором на этой неделе я буду показывать, как писать zod, я решил выпустить несколько видео с актуальной для меня темой.

В последнем видео я показал, как сделать todo-list на typescript типах 🤯

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

Выложенного на youtube не вырубишь топором, и я решил рассказать об этом тут)

Для начала – для чего нужны вообще типы? 🤔

Я выделяю 3 важные вещи:
1. Описание контрактов
2. Автодополнение
3. Защита от глупых ошибок

В результате, с помощью ts можно писать 2-3 часа код, запустить, и он заработает.
Не надо постоянно запускать код и смотреть, что там в объекте за поля. Не нужно всё время ползать в доку библиотек, чтобы вспомнить название метода. Не нужно ползать по кодовой базе, чтобы узнать, а может ли в поле придти undefined, или оно обязательное.

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

А теперь: для чего сложные типы? 🤔🤔🤔

Задачка, как типизировать такое?

function sortByStringKey(objs, key) {
  return [...objs].sort((a, b) => a[key].localeCompare(b[key]));
}

Не просто, да? На самом деле, это базовый пример полиморфной функции – функции, которая работает с разными типами данных! А из-за того, что она иммутабельная, мы тут обязаны использовать дженерики

Вот так выглядит одна из версий типизации:

type OnlyStringObjectKeys<T> = {
  [K in keyof T]: T[K] extends string ? K : never;
}[keyof T];

function sortByStringKey<T extends Record<string, any>>(
  objs: T[],
  key: OnlyStringObjectKeys<T>,
): T[] {
  return [...objs].sort((a, b) => a[key].localeCompare(b[key]));
} 

const books = [{ id: 3, title: "To Kill a Mockingbird", author: "Harper Lee" }]
const sortedBooks = sortByStringKey(books, "author");

Тому, кто не привык к типам, это покажется очень сложным. Но что делает этот код?

1. Здесь тип возвращаемого значения будет зависеть от типа первого параметра, так как они используют один параметр типа Т
2. Тип параметра key зависит от типа objs, как чтобы в key были только ключи из objs содержащие строки.

Таким образом, типизировав подобным образом, мы получим следующие фишки:
1. При изменении objs, typescript выдаст, что key неверный. Если нужно, реализуется защита от глупых ошибок. А так же на key работает автокомплит.
2. Тип возвращаемого значения зависит от типа параметров, и поэтому на возвращаемом значении работает автокомплит

А теперь подумайте, для какой функции важнее, чтобы хорошо работал автокомплит и защита:
- для функции, которая используется один раз?
- для функции, которая используется кучу раз с разными типами данных?

Очевидно, что для второй! Так как каждый раз, встречая такую функцию, вы будете использовать преимущества строгой типизации в виде строгой типизации и автокомплита. Но, к сожалению, именно типизация переиспользуемого кода – самая сложная задача

А теперь вспомните, сколько раз вас останавливало банальное незнание сложного typescript от написания удобной инфраструктуры и хелперов, которые бы сильно упростили клиентский код?

В своё время поэтому я и выучил сложный ts. Я всегда любил простоту, чтобы везде работал автокомплит, а еще любил переиспользовать код. И МНЕ ПРИШЛОСЬ выучить typescript.

На самом деле, typescript достаточно прост! Просто нужно выучить совершенно новый синтаксис и знать пару фишек, об этом как раз в курсе в сообществе я и рассказываю)

Пора признать: я дофаминоголик

Вы, наверное, встречали людей алкоголиков, наркоманов, игроманов.

Их всех объединяет одно: они не могут умеренно употреблять!
Они могут какое-то время контролировать свою зависимость. Но всё время воздержания они либо апатичны, либо раздражены. Вся жизнь сосредоточена вокруг получения новой дозы.

Они даже могут много лет держаться, но однажды подумать: "Я уже 3 года не пил, ничего не будет от одной кружки пива". И вот через месяц они валяются под забором в неадекватном состоянии.

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

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

Но мне и не нужно было употреблять алкоголь, чтобы быть алкоголиком.

В эту субботу я играл 15 часов подряд. 2 недели назад я читал книгу 15 часов подряд, ещё до этого я читал хабр 15 часов подряд. Бывало youtube смотрел, бывало шортсы/рилсы/ тиктоки меня затягивали.

Все последние 3 месяца я искал ответ:
Я так хочу провалиться в это из-за того, что это моя потребность. Или я просто зависимый?

Искал способы умеренно упротреблять. Но всё заканчивалось одним и тем же. Жена страдает, а я пропал на 1-2 дня со всех радаров...

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

Но если они зависят от алкоголя, я зависим от всего лёгкого дофамина. Я настоящий Дофаминоголик.

И как у Алкоголика, для меня есть только одно решение:

Полное воздержание!

Результат 👉🏻 5 дней я не:
- Читал новости
- Смотрел youtube
- Играл в игры
- Листал шортсы
- Смотрел фильмы и сериалы
И вообще воздерживался от всего "легкого, неограниченного физически дофамина"

Ощутил освобождение. Прилив сил и мотивации. Снова начал себя ощущать сильным и энергичным.

Да, это только начало пути. Но всё всегда начинается с осознания проблемы. И я её осознал!

Я дофаминоголик. И меры должны быть соответствующие.

Признание своих слабостей – это сила. Ибо только так мы можем их нивелировать

Этой весной я на holy.js в новой роли

Пока я тут боролся со своими зависимостями, проворонил время подачи заявки на holy.js.

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

Буду помогать Александру Моргунову рассказывать про FSD. Эксперты – это уникальная для jug.ru штука. По факту, ты снимаешь с докладчика ряд ответственности, помогаешь настроиться на доклад и управляешь QA частью.

У меня всегда были немного отличные от Саши взгляды на FSD, но от этого и дискуссия будет интереснее 😉

А ешё я выступлю с мини докладом на открытом микрофоне. Это будет шуточный доклад про "Божественный тип Any" и чем он такой божественный)

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

Так что, если кто хочет увидеться, приезжайте тоже. Благо мне тут птичка нашептала, как можно купить билеты со скидкой 25%. Кому интересно, пишите – расскажу)

Приехал с holy.js – впечатления:

1. Очень качественная и классная организация!! Всё бесшовно и на высшем уровне.
2. Быть в тусовке спикеров – ТОП, всем советую. Тонна интереснейшего общения и новых знакомств.
3. Отдельный кайф, когда подходят фоткаться и говорят, насколько сильно мои видео и курсы помогают людям. Приятные слова от живых людей дают супер эмоции 🤗
4. Караоке до 4х утра с лучшими умами фронтенда – это легендарно)
5. Ещё все приезжайте на MoscowJS и BeerJS. Там лучшие люди!
6. Господи, как же я люблю экспертно затирать на большую аудиторию. Хоть был экспертом, но не упустил возможности вставить своё мнение. Надеюсь, Саше было комфортно)


Второй раз на holy.js, но уже так много знакомых, и все такое... родное, чтоли. Ооочень душевная конференция получается ☺️

Уже готовлю темы докладов на осеннюю holy. Хочу сделать это для себя приятной традицией)

Месяц отказа от Игр, Youtube, Новостей

Месяц назад я понял, что я "зависимый человек". Это особенность моей генетики и моей личности. Тогда я решил полностью отказаться от источников моей зависимости.

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

Но как это вообще сработало, почему именно полный отказ?

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

У зависимого не наступает насыщения. Вот я поиграл 16 часов, и, думаете, я наигрался? Нет. Я хочу на следующий день ещё. Ещё и ещё, пока не начинаются реальные проблемы и физические ограничения.

После того как я поиграл, я всю неделю думаю о том, как поиграю снова. Нет желания жить, достигать, развиваться, вообще что то делать.

Но почему я так легко отказался полностью?

Тут есть несколько факторов:

1. Мозг намного проще относится к категоричным позициям. Поэтому все так любят вешать ярлыки типо "Redux говно", "Женщины дуры".

От некатегоричных позиций появляется внутренний диалог, который у зависимого всегда приводит к "А почему я вообще должен себя ограничивать?"

2. Я использую веру)

Почему люди готовы были убивать за идеологию или веру?
Категоричная позиция + постоянные повторения = глубокая убеждённость

Я давно заметил, что пропаганда работает, даже если ты понимаешь, что это пропаганда. Просто множественное прослушивание уверенного утверждения --> внутренняя неосознанная убеждённость

Теперь я использую этот эффект себе во благо. Погружая себя в свою же пропаганду полного отказа (сам придумал, сам везде расклеил, сам поверил, кайф)

3. Я делаю это не один.

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

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

КОРОЧЕ, ПОЛНЫЙ ОТКАЗ НАМНОГО ПРОЩЕ!!!

В результате, уже 1 месяц я живу в полном отказе. И мне так легко, как не было никогда!

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

А самое главное — как приятно чувствовать искренний интерес к жизни, к работе, к людям вокруг. Как приятно вновь испытывать ЯРКИЕ эмоции и ощущения от жизни.

Жизнь в лёгком дофамине – это когда тебе всегда "НОРМ"

Жизнь без лёгкого дофамина – это американские горки между удовольствием, страхом, интересом, разочаованием, восхищением.

И как и с пульсом: чем больше колебаний, тем ты живее. Чем меньше... думаю, вы поняли.


P.S. на видео я трезвый

Шутка, которая вышла из под контроля

Меня до сих пор бесит состояние вокруг стейт менеджеров в react.

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

Например:
– Однонаправленный поток данных.
– Иммутабельность
– Банчинг

Чтобы доказать эту идею нужен целый доклад 😉 Сейчас просто считайте это моей позицией

Но, к сожалению, у локального React состояния есть важные минусы:
– Оно привязано к жизненному циклу реакта
– Оно привязано к структуре компонентов
– И, вроде, есть контекст для решения второй проблемы, но нет точечной подписки

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

И нет бы просто взять то, что есть в React и просто решить проблемы. НЕЕЕТ, надо ввести кучу своих концепций, напридумывать всякие санки, саги, прокси, потоки, эффекты, эвенты.... 🫠

И вот нам приходится сначала учить React, потом стейт менеджер. А потом пытаться как-то натянуть одно на второе.

---

Недавно, накануне первого апреля, я заглянул в исходники React и обнаружил там интересное:

import * as React from "react";

const ReactSharedInternals =
  React.__CLIENT_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE;

const useState = ReactSharedInternals.H.useState

Оказывается, реализация хуков в React – это динамическая штука. Значит их можно подпихнуть в эту переменную когда угодно и заменить реализацию.

И тут у меня родился коварный план 😈

ХОЧУ КАК REACT, ТОЛЬКО ГЛОБАЛЬНО. А ЕЩЁ С ТОЧЕЧНОЙ ПОДПИСКОЙ.

И в результате некоторого исследования получилось вот это:

import { createGStore } from 'create-gstore';
import { useState } from 'react';

// Define a global state from a hook
const useGlobalCounter = createGStore(() => {
  const [count, setCount] = useState(0);
  
  const increment = () => setCount(count + 1);
  const decrement = () => setCount(count - 1);
  
  return { count, increment, decrement };
});

function CounterButton() {
  const { count, increment } = useGlobalCounter();
  return <button onClick={increment}>Count: {count}</button>;
}

function CounterDisplay() {
  const count = useGlobalCounter(s => s.count);
  return <div>Current count: {count}</div>;
}

Вы это видите?)

Это обычные React хуки, которые работают как React хуки. Но только состояние привязано не к компоненту, а к глобальному хранилищу.

Уже реализована поддержка: useState, useMemo, useCallback, useRef, useEffect, useLayoutEffect, useSyncExternalStore

Короче, написал это. Посмотрел...

А потом до меня дошло. Ведь огромное количество моих локальных хуков без изменений можно сделать глобальными. В том числе и библиотечные react-hook-form, react-query!

И в этот момент я понял, что это уже имеет шансы стать не просто шуткой)

---
Вы уже можете установить себе и опробовать это. Благо, учить воообще ничего не надо. В доке есть куча примеров.

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

Жду вашей обратной связи и ишьюсов на github)
Очень интересно, что вы думаете!

Документация:
https://evo-community.github.io/use-gstate/

github:
https://github.com/evo-community/use-gstate

За обучение должен платить работодатель

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

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

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

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

Здесь получился просто колоссальный прогресс. Они пришли ко мне недавно закончившими курсы. А через год уже шарят за FSD, ООП, Dependency Inverson, Dependency Injecton, пишут классный модульный и надёжный код. Активно используют событийную модель. Кроме базовых: react, redux. Изучили новые инструменты: mobx, react-query, tailwindcss, shadcn, tanstack-table. А самое главное, научились их эффективно использовать.

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

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

А что от этого работодателю?
– выполненные в срок задачи
– маленькое количество багов
– довольные работники
– сложные архитектурные/инфраструктурные задачи решаются быстро и без проблем 🫠

То есть это вообще лайфхак:
Работодатель получает: качество и стабильность разработки сеньора по цене джунов
Работники получают: Быстрый рост и комфорт на проекте (у них реально классный код получился)

В общем, крайне интересный формат выходит. И я хочу его масштабировать.

Так что, ребят, если у вас есть желание поработать со мной в формате командного менторинга/ консалтинга – пишите мне, расскажу про условия)

leptos – rust fullstack framework

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

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

И вот в этом порыве решил изучить rust. На это есть несколько причин:

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

– На rust сейчас переписывают вообще всю фронтовую инфру. И линтер для evolution design я хочу тоже сразу на rust писать.

– Просто в процессе написания процедурной генерации столкнулся с тем, что мой код работает 5 секунд, а должен 100мс. Переписал на rust и легко уложился в нужную производительность.

Возвращаюсь к теме поста: leptos.

Я – фронтендер. И как мне изучить rust? Можно начать кодить какие-то консольные утилиты, но это скучно.
Хочется делать что-то готовое, чем можно пользоваться...

И, знаете, а ведь front-end можно писать на rust)

Вы можете взять и скомпилировать ваш rust код в wasm, отправить на front и запустить своё blazing fast spa приложение со сложными вычислениями на клиенте (например, игру)

Более того. Уже существует достаточно большая экосистема:
➖leptos: полноценный react/vue/solid like фреймворк, со своим jsx и реактивностью
➖web-sys: биндинги большей части web-api на rust, чтобы можно было вообще всё писать на rust и в js даже не заглядывать
➖куча backend фреймворков, чтобы можно было написать свой сервак

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

Как я учу rust, кому интересно:
✔️прочитал бегло доку, особе нигде не задерживаясь
✔️вместе с cursor накидал небольшую игру
✔️попросил cursor обяснить вообще всё, что я написал. Прям пока каждую строчку не понял (лучше всего это делает gpt-4.1 модель)
✔️дописал уже кусок кода по памяти
✔️пошёл перечитывать доку в поисках нюансов. На почву практики инфа садится отменно

Так часов за 20 в общей сложности чувствую себя джуном в rust. Думаю, это прям быстро. Всем советую такой способ!

Вообще, про обучение с AI инструментами сделаю отдельный контент. ЕСЛИ ИХ ИСПОЛЬЗОВАТЬ ПРАВИЛЬНО, то это сууупер эффективная тема.

Этой осенью выступаю на FrontendConf!

Расскажу о своём детище, которое сейчас активно развивается – evolution design

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

Про evolution design

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

Поэтому я пошёл думать, и о ED не было слышно некоторое время.

Но после большого количества общения, менторинга, написанного кода, я понял, что готов подступиться второй раз.

В чём основная идея ED? И почему меня не устроил сам FSD?

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

Я немного подпилил напильником и стало лучше.

Потом время шло, FSD стал популярнее, и я решил поделиться своей экспертизой в курсе (который доступен в моём сообществе сейчас)

И до 4 урока, курс по FSD – это курс по FSD. Но в 5 уроке я поднимаю вопрос "недостатков" и представляю свою модификацию.

Таким образом, курс по FSD, по факту не про FSD. И, в целом, когда я говорю о FSD, имею ввиду не сам FSD.

Более того! Когда я говорю с другими опытными разработчиками о FSD, мы говорим не о FSD)

Когда я начал ездить на конференции и менторить, оказалось, что на чистом FSD успешно почти никто не пишет.

Более того, оказалось, что многие действительно успешные кейсы модификаций очень похожи. Мы разговаривали с Денисом Черновым, и его архитектура очень похожа на мой ED.
Недавно в чате FSD один из самых активных участников рассказывал про свою структуру. И, о боже, она тоже 1 в 1 ED small)

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

Я решил просто задокументировать результат ресёрча всей отрасли!

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


В результате я хочу, чтобы вам не пришлось говорить: "У меня FSD, но с модификациями. Сейчас объясню какими"
А вы могли сказать: «У меня ED в модификации medium. Вот документация и видео курсы, в которых это рассказано.

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

Самое сложное в этом всём – не усложнить)

Чем гибче код, тем он сложнее. С архитектурой также. Но я хочу этот момент перекрыть
а. Постепенностью. ED small проще, чем FSD
b. Просто тонной образовательных материалов.

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

Хочется всё рассказать, но для этого есть документация:
ed.evocomm.space

А если у вас есть вопросы и пожелания, залетайте в чат ED:
https://t.me/+VugvWY1dtdRhM2Uy

1/2 Чему меня научил экзистенциальный кризис:

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

Кризис – это учитель. Кризисы наступают, когда ты закрываешь глаза на проблемы. Вместо того, чтобы их решать, ты думаешь «да не, всё норм. Это так, дискомфорт, пройдёт.»

А потом: херааааааак! И вот уже на проблему нельзя не обращать внимание)

Так у меня и случилось. Лёгкий дискомфорт превратился в апатию, и уже пришлось что-то делать.

Какие у меня оказались проблемы

Первый и самый сложный этап в кризисе – найти проблему. Ну то есть тебе хреново, всё катится в тартарары, но почему – хрен знает 🤷🏼‍♂️

Я на этом этапе перепробовал всё: Режим, питание, зал, общение, отсутствие общения, близость с женой, отдаление от жены, много работать, мало работать...

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

Я не обращал внимание на свои желания

Многим из нас родители говорили в детстве: мало ли что ты хочешь, я тоже много чего хочу

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

Смотришь одних: Надо зарабатывать деньги и строить бизнес
Смотришь других: Зож, спорт, правильное питание
Смотришь третих: Тусить, общаться, связи строить
Смотришь четвертых: Изучать устройство процессора и паттерны программирования.

И в этом всём есть 2 варианта.
Либо следование за чужими ценностями закрывает твои потребности, либо нет. В первом случае тебе будет норм, а вот во втором случае неминуем кризис.

Как раз уход с работы программистом запустил у меня этот кризис. Обстоятельства изменились и "надо" со временем стало совершенно невыносимо.

2/2 Моя главная потребность

После долгих месяцев мучения, я наконец смог признать:
Сложная, отречённая, погружённая, интересная деятельность – потребность №1 для меня

Программирование, изучение нового, чтение книг, игры. Если у меня этого нет, через 5 дней мне станет хреново.

Более того, мне этого нужно прям много. После исследований себя оказалось, что часов 20 в неделю.

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

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

Как я вписал потребность в жизнь?

После осознания своей потребности встал вопрос: а как теперь с этим жить?

В одну жизнь нужно вписать 4 важнейшие потребности:
1. Интерес
2. Жена
3. Деньги
4. Отдых
Сначала я пытался всё это вписать в день. Но так получалось, что я скакал между кучей деятельностей, и всё получалось плохо.

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

Так у меня и родился режим, которому следую уже 3 недели. И в котором я себя ощутил устойчиво, как никогда.

3 дня - дела, деньги
2 дня - интерес
2 дня - отдых

Я человек-погружение. Мне очень сложно переключиться. И я решил минимизировать переключения.

Поэтому в начале недели я 3 дня сутками работаю. Записываю видео на youtube. Курсы в сообщество. Те вещи, которые нужно делать. Но которые недостаточно сложные, чтобы закрывать мою потребность в интересе.

После наступает моя любимая часть. Я отправляюсь в мир своих грёз. За эти 3 недели я выучил основы webgl, rust, написал небольшую игру, и начал разрабатывать на rust архитектурный линтер для ED. Здесь я следую за своими желаниями (Важно: исключая зависимости. Иначе это бы не работало)
После этих двух дней я чувствую себя счастливым, наполненным, но уставшим)

Поэтому дальше идёт 2 дня гига чила.
Я вообще выключаю компьютер. И просто гуляю, хожу в лес. Жгу костёр. Много времени провожу с женой и ребёнком.

Результаты этого режима уже дают плоды

Я снова вернулся на youtube. Начал чаще писать сюда посты. Начал развивать evolution design и мой стейт менеджер create-g-store. Конечно, продолжаю записывать супер топовые и уникальные курсы в сообщество. И скоро там появится контент по трудоустройству от моих хороших знакомых.

А самое главное. Я счастлив и удовлетворён

В общем спасибо саморазвитию и психологу. Я снова живу. И снова готов двигать горы)

Возвращаюсь из пещеры)

Я на пару недель пропал, так как все силы положил в совершенно уникальный видос:
https://youtu.be/Qt5LpjP3siI

В нём я показываю, как на чистом React можно разработать копию miro.
При этом здесь используются паттерны ООП, адаптированные под React. А именно, state и decorator

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

Вообще, давно хотел записать такое видео, где показано как разрабатывать нетривиальные интерфейсы на чистом React.

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

Как по мне, наоборот, концепция однонаправленного потока данных и имутабельность позволяет описывать очень сложные вещи простым и надёжным способом. Просто надо научиться кодить без useEffect для логики. (Здесь, кстати, использовано всего 2 useEffect, и оба нужны только для взаимодействия с dom)

Если хотите научиться также, в сообществе есть курс «58 React паттернов», в котором описаны подходы из видео. А также их плюсы, минусы и границы применимости

Ещё в видео есть много интересных мест со сложной ui логикой:
– Как рисовать динамические стрелки на svg
– Как одним ref получить размеры всех нод на экране
– Как сделать бесконечную карту с зумом и перемещением

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

Про оптимизации

Недавно мне задали вопрос:
«Что делать, если табличка лагает? Вроде memo накинул, а всё равно медленно»

В таких ситуациях у меня первый вопрос:
"Профилировал? В отрисовке дело, или в react?"
Ответ был: «Конечно же, не профилировал»

И тут я понял, почему все так носятся с этими useCallback, React.memo. Сравнивают React с Vue/Solid и говорят, какой же он медленный.

Большая часть людей никогда даже в профайлер не заглядывала.

А если заглянуть… Да не просто заглянуть, а собрать прод сборку и накинуть замедление CPUx4. То часто оказывается интересная картина.

React рендер занимает, условно, 9мс, а отрисовка браузера 30мс (то, что в профайлере фиолетовым и зелёным)

И тут, следите за руками 🧙‍♂️

Вы берёте и героическими усилиями оптимизируете отрисовку реакт в 3 раза!!! О боже, как же быстро всё должно теперь работать

А теперь посчитаем:
Изначальное время отрисовки 9 react + 30 браузер = 39
Конечное время 3 react + 30 браузер = 33
(33 - 39) / 39 = 15%

Оптимизация React в 3 раза на самом деле ускоряет результат всего лишь на 15%

Почему так получается? Да очень просто. Оптимизировать нужно бутылочное горлышко! Мы тут хоть React вообще уберём, но быстрее 30 мс работать не будет! Простая математика

Поэтому оптимизировать без профайлера – это ананизм

Но многие скажут: «Так нет же! Я профилировал. И там React – это огого, как долго!»
Но дьявол, как всегда, в деталях. В Dev сборке React накидывает просто тонну оверхеда. Кучу отладочной информации, strict мод, где всё работает по кучу раз, и постоянные проверки правил хуков и подобного.

И при замедлении React в dev версии мы получаем, что он начинает быть соизмерим (или больше) с отрисовкой по вкладу.
Но это обманчиво! На деве React медленне. Но браузер на проде и деве то одинаковый!

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

Итог. Если работает медленно – идём в профайлер. Отимизации слепого котёнка – полная бессмыслица

☝️Если вам интересна тема профилирования, то в это воскресенье в сообществе пройдёт воркшоп «Профилирование и оптимизация React кода»

Где мы на примере miro доски:
✔️ Научимся искать бутылочные горлышки.
✔️ Посмотрим способы оптимизации React рендеров без изменения архитектуры
✔️ Напишем простую виртуализацию
✔️И разберемся с фазами отрисовки бразузера

В результате вы научитесь понимать, что там вообще в профайлере за белиберда. И как профилировать, чтобы результаты не врали)

Приходите, будет интересно! 🔥

Вот, что мне не нравится в effector

Я долго не касался темы effector в контенте, так как не было достаточного опыта взаимодействия с ним.

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

Но начну с хорошего:
В эффекторе есть идея, которая мне очень нравится – эвенты выделены, как сущности

Это позволяет строить инверсию зависимостей (управления). И по этой причине на effector просто писать по fsd.

// Эвент определяется в месте где его вызвают
export const buttonClicked = createEvent();
export const Button = () => <button onClick={() => buttonClicked()}>text</button>

// В любом месте можно на него подписаться
$counter.on(buttonClicked , (count) => count + 1);

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

Effector своей философией пытается всё "поджать" под себя.

Ну то есть. Из-за обилия инверсии (эвент, стор и реакция на эвент – это всегда разные сущности)
Писать правильно на effector очень сложно.

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

А как раз этот гайдлайн максимально "категоричный"

В речи фаната effector вы обязательно услышите утверждения:
1. Нужно отделить модель от отображения. Иначе говнокод
2. Бизнес логики не должно быть в ui
3. Ты должен писать бизнес логику так, чтобы можно было убрать react и заменить на условную консоль
4. В хуках не может быть никакой бизнес логики, так как это view слой
5. Бизнес логика – это любая работа с данными, которая не завязана на отображение
6. Effector – идеальный инструмент для описания сложной логики. На хуках только кнопки красить

Я с этими тезисами не согласен. Но на выражение моего мнения потребуется сильно больше одного поста.

В результате этих утверждений получается следующее:
1. Все hook first библиотеки в топку. Так как это привязывает логику к отображению. Мы должны всё перевести на effector
2. Запросы на хуках в топку – это бизнес логика
3. Локальное состояние в топку – это тоже бизнес логика. А бизнес логика должна быть вне компонентов

Результат:
1. Всё становится глобальным состоянием. Сложно переиспользовать код. Нужно писать фабрики, а это ещё сложнее, чем чистый эффектор
2. Effector заполняет собой всё пространство и вытесняет всю React инфраструктуру, заменяя ее effector инфраструктурой. А что нет в effector, приходится писать велосипеды из хлебного мякиша
3. Всё в effector – инверсия зависимостей. Так как по версии effector вся работа с данными это бизнес логика - всё приложение должно быть на effector. Теперь даже самые простые компоненты становятся сложными.
4. Да, сложный асинхронный флоу можно описать красиво. Но обычно сложного в приложениях не так много.

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

Зафиксируем мое мнение на этом моменте. Мне еще предстоит долго работать с этой кодовой базой. И я не стесняюсь переобуваться. Поживем увидим 🤌🏼

И забавное наблюдение напоследок. За последний год я встречаю уже не первую историю, как один человек затащил effector, а потом всем он не нравится. Но выпилить либо слишком долго, либо сложно 🫠

Самый полезный видос, который никому не нужен

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

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

Но в этом видео я решил вернуться к корням.

Вы слышали, что такое DSL?

Если нет, то вы скорее всего считаете что html – это не язык программирования)

Но, на самом деле, html – это самый что ни на есть язык программирования. Только созданный не для всего подряд, а под специфическую задачу. Такой Domain Specific Language

А что если я вам скажу, что вы можете добавить на свой сайт DSL всего за 30 минут.

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

Вы спросите: "А нахрена?"

А я вам отвечу:
Следующий раз, когда вы будете делать админку и пилить какой то сложнючий интерфейс для 3,5 пользователей – подумайте. А может быть им проще будет просто описывать это всё текстом, а не муторно натыкивать из интерфейса.

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

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

А, возможно, проще было бы просто сделать для этого DSL?

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

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

Как завернуть в Docker vite приложение

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

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

В сообществе есть воркшоп, о котором я не рассказывал – Как докеризировать Vite приложение.

Там я рассказываю, почему писать Dockerfile должен разработчик, а не DevOps. Как правильно это делать, как оптимизировать размер имеджа и скорость сборки.

А ещё я там рассказываю, как можно изменять переменные окружения в уже собранном имедже Vite приложения.

Последний момент не очевидный, так как переменные окружения в Vite приложении записываются в бандл во время сборки, и во время запуска контейнера их уже вроде как не изменить. Что очень не удобно для DevOps

Решение, на самом деле, простое. На запуск контейнера можно заменять значения переменных окружения в уже собранных js файлах. Я показал это решение вплоть до исходников на воркшопе. + Как решить проблему с кэшированием, которая может тут появится

И вот на днях созваниваюсь я с одним участником сообщества, а он мне рассказывает:

"Стала мне тут задача написать Dockerfile для проекта. Я вспомнил про твой воркшоп. Просто взял из Miro код, и всё завелось! Особенно было полезно как раз про переменные окружения. Так как совершенно не очевидно, как это делать.
В общем, не знаю, сколько это бы сам делал"

Вообще, от воркшопов сообщества много таких отзывов. Одни затаскивают код JWT авторизации c рефрешем, другие ролёвку, третие oauth, четвёртые форм билдер.

Это меня очень вдохновляет. Приятно понимать, что мои знания упрощают жизнь множества разработчиков (а не только усложняют кучей часов сложного глубокого контента 🫠)