Как я перестал исправлять ИИ код и начал проектировать под него архитектуру

Абсолютно с вами согласен, оставляя существующий проект на съедение вайбкодингу, без какого либо рефакторинга и контроля того, что пишет ИИ — учесть проекта сведётся к нечитабельному коду, дубликатам и хаосу, ну и ещё ИИ все равно будет труднее понимать такой проект. Увы руководство и менеджеры вышестоящие над разработчиками не всегда это понимают и больше заставляют забывать о качестве и выдавать количество (функционала)

Как я перешёл с React на Angular и не пожалел

Да, так в основном и строятся крепкие веб приложения сейчас. Мы вместо rxjs используем mobx только

Дыра в безопасности в Ze-Post: как подменить личность любого пользователя в мессенджере MAX

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

В итоге я , как и несколько других разработчиков, видят очень много багов, их заводят, но ничего с ними не делают (хоть я лично и хочу, чтобы наша система была идеальной)

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

MobX или приправа реактивности для JS

Спасибо за комментарий! По пунктам:

1. Порядок рендера - не проблема. useValue в проде использует useRef-паттерн ленивой инициализации, экземпляр привязан к конкретному хуку, а не к порядку вызовов. С ViewModelStore дополнительно работает пуллинг по id - повторного создания не будет.

2. Отброшенный рендер - актуально только для сценария без ViewModelStore, что не основной кейс. С ViewModelStore viewModels.attach() просто инкрементит ref-count, что безопасно. Без стора действительно есть ограничение при работе с Suspense - это описано в доке. Перенос mount() в Layout Effect решил бы его, но требует нетривиального рефакторинга - синхронный mount в рендере нужен для SSR и совместимости с mobx-react observer.

3. StrictMode - работает корректно. В проде useRef сохраняет экземпляр через unmount/remount, lastAttachedInstanceRef предотвращает повторный attach. В дев режиме useMemo может пересоздать экземпляр при remount, но пуллинг по id в сторе не даст дублирования, а без стора очистка отработает корректно. При этом лично я StrictMode не использую - на мой взгляд, инструмент, который меняет поведение в дев и не идентичен поведению в продакшне, применять нельзя.

MobX или приправа реактивности для JS

в одном компоненте - будет лишний ререндер.

Насколько я знаю лишнего рендера не будет, потому что 18+ реакт будет автоматически батчить такие апдейты, но mobx реакции вызовутся два раза да

MobX или приправа реактивности для JS

Привет, все зависит от того как писать !

У нас тоже были утечки памяти, но они были связаны с тем, что в некоторые reaction не были прикинуты сигналы на удаление

reaction(
    fn1,
    fn2,
    {
      signal: this.abortSignal
    }
)

В общем утечек памяти в самом observer я с уверенностью могу сказать что нет, потому что у нас вкладка с фронтом (два фронта: главное приложение + iframe приложение внутри) после работы GC занимает память 84-86 МB

Важный момент: мы не используем React хуки вовсе в слое представления для БЛ (кроме юайных хуков вроде useTable), поэтому прокси не отправляются в массив зависимостей в хуках, как и не используются в замыканиях в хуках. Это может быть связано с утечками

MobX или приправа реактивности для JS

Да, спасибо за внимательность, допишу об этом моменте в статье!

Этот варнинг убирается через настройку

import { configure } from "mobx"

configure({
    enforceActions: "never"
})

MobX или приправа реактивности для JS

Привет!

В данный момент мы разрабатываем чисто CSR апку, но на гитхабе у меня можно найти пример работы MobX в режиме SSR (GOZON), а также да, как вы упомянули, можно использовать mobx-tanstack-query + написать некий стор который имеет базовое состояние-слепок стейта

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

Что то кнопка зарегистрироваться не работает

Разбираем Bulletproof React: как не утонуть в хаосе собственного кода

Золотое правило: Если компонент не переиспользуется в двух+ фичах, ему не место в общей components. Он должен жить внутри своей фичи.

Получается если компонент будет переиспользоваться в двух+ фичах, то ему место в общей components? Это же тот же хаос создастся:)

Типобезопасный HTTP API на TypeScript без кодогенерации: @cleverbrush/server и @cleverbrush/client

Честно скажу выглядит очень красиво и аккуратно!

На счёт клиента для фронта увидел такой код, не совсем понял откуда берется api, предполагаю что это целое апи из бэка

import { api } from '@some-shared-library/contract';

const client = createClient(api, {
    baseUrl: 'https://api.example.com',
    getToken: () => localStorage.getItem('token')
});

Если это так, тогда вопрос как обстоят дела с тришейкингом? Не потянется ли в бандл весь api для того чтобы работала типизация на фронте?

Подписка на нейросеть Claude: как оформить доступ быстро и безопасно

Нейростатья + реклама своей платформы 👍

Zed 1.0: эпоха Electron-редакторов — всё

Интересно сравнить что быстрее neovim или zed

Frontend Status: свежий дайджест фронтенда и AI — 18.04.2026

Очень сочный и полезный дайджест, спасибо!

Нормализация состояния в React через реестр сущностей: паттерн на Zustand с рекурсивным парсингом и мягкими удалениями

Тот же пример на "всеми" нелюбимом стейт менеджере...

const UserList = observer(({ userIds }: { userIds: UserId[] }) => {
  const users = userIds
    .map((id) => userStore.users[id])
    .filter(Boolean); 

  return (
    <ul>
      {users.map((u) => (
        <li key={u.id}>{u.fullName}</li>
      ))}
    </ul>
  );
});

Нормализация состояния в React через реестр сущностей: паттерн на Zustand с рекурсивным парсингом и мягкими удалениями

Причём как правило достаточно использовать observer и computed.

И никаких useShallow :)

Хватит просто писать код, попробуйте в нём выжить. Представляем GitCrab 1.0

Взяли в прод, спасибо!

FE-разработчики, перестаньте буквально воспринимать дизайн

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

FE-разработчики, перестаньте буквально воспринимать дизайн

Тогда не представляю как должно быть "правильно" для этого элемента ввода, с точки зрения UI/UX, потому что растянуть список по высоте до размеров экрана это неполноценное решение, которое все равно заставит скроллить, а отображение огромного модального окна чтобы выбрать эти элементы тоже, на мой взгляд, странно

Как React обновляет UI: trigger → render → commit

В статье не хватает рецепта свиных крылышек