Практически 100%. Цель была - настроить полностью автономный конвейер ИИ-агентов. Но не получилось. Где-то на 1/3-1/2 пути пришлось в ручном режиме управлять. В time-travel много кода. С учетом количества и объема рефакторингов и покрытия тестами руками я бы это не сдюжил
Философия — Zustand: одно хранилище, минимум абстракций. Быстро, просто, «меньше магии». — Nexus State: состояние как сеть независимых атомов. Изоляция, явные зависимости, предсказуемость в сложных сценариях.
// Форма: валидация email
// Zustand: в компоненте или через вычисляемое поле в store
// Nexus State: производный атом с чёткой зависимостью
const isValid = atom(get => /^[^@]+@/.test(get(emailAtom)));
О формах — Zustand: удобно для простых форм. Легко сбросить всё состояние. Отлично дружит с react-hook-form. Валидация — в логике компонента или через доп. поля. — Nexus State: каждое поле — отдельный атом. Обновление имени не триггерит ререндер email-поля. Идеально для динамических форм, кросс-валидаций, глубокой изоляции. Сериализация для SSR — встроенная (store.extract()).
Итог — Выбираете скорость и простоту? → Zustand. — Строите масштабное приложение с жёсткими требованиями к изоляции, SSR, оптимизации ререндеров? → Атомарный подход.
Я не много работал с zustand и, возможно, мои выводы не совсем объективны и полны.
По поводу MobX дополню: в экосистеме есть инструменты вроде mobx-state-tree (сериализация, flow для асинхронки) и паттерны для ленивой загрузки, но вы правы — они требуют дополнительной настройки и не встроены «из коробки». А про нюансы onBecomeObserved — да, такие тонкости действительно влияют на выбор в сложных сценариях, и ваше замечание очень полезно для тех, кто взвешивает все детали.
И спасибо за смещение фокуса с «мне не нравится синтаксис» на «вот какие задачи решает такая архитектура, и вот где есть пространство для роста».
Привет! Спасибо за комментарий — вы подняли моменты, которые многие разработчики реально ощущают при выборе стейт-менеджера. Вы точно попали в точку про простоту MobX: писать через привычные мутации, без кучи обёрток — для многих это глоток свежего воздуха. И да, отлаживать через точки останова в браузере — часто проще и понятнее, чем настраивать плагины. Особенно когда команда уже «в теме» и знает, как работает реактивность. Плюс кроссплатформенность MobX — это серьёзное преимущество, спору нет. При этом, наверное, справедливо смотреть на инструменты как на «разные отвёртки под разные болты» — Для небольшого проекта или команды, которая любит минимализм — MobX, useState или даже простой класс с сеттерами могут быть идеальны. — Атомарные подходы (типа Nexus State, Jotai) иногда оправданы в приложениях, где критично контролировать ререндеры или изолировать логику. Но вы правы: для счётчика писать store.set(countAtom, 5) — это явный перебор. Главное — не абсолютизировать ни один подход. У каждого решения есть своя аудитория, свои задачи и компромиссы. Ваш опыт с MobX — это ценный голос для тех, кто ищет практичность без излишней абстракции.
Согласен. @ в пароле тоже "ломает" схему. Поправлю текст.
Что касается названия, то я сам искал настройку proxy в Ubuntu для WSL. И, видимо, поэтому название получилось несколько "зашоренным".
Согласен. Предлагаемый в статье подход подразумевает ручную замену значений в достаточно большом количестве мест. Предлагаемый вами подход представляется перспективным. Но не смог найти примеров и/или реализовать самостоятельно определение и использование нужных переменных окружения для настройки wget и curl в случае наличия спецсимволов в логине или пароле.
Спасибо за замечание. Это была опечатка. Исправлю. Написано ради кейса с @ в логине. В моем случае написанные ранее статьи не помогали, так как в результате следования им я получал отказ в авторизации.
Так мы говорим про агентов или про запросы к АПИ?
И может быть получится найти хоть какой-нибудь пример в подтверждение?
Чтобы уж не морочить никому голову путаницей из терминов
Описанный в статье способ расширения функциональности — приложения. А конкретнее приложения 1-го типа (в терминологии документации). На каком этапе здесь могут быть использованы агенты или проявляется влияние особенностей их работы?
Если данные не скопировать в образ и попытаться запустить его например на AWS, то некрасиво получится, так как они (данные) в этом случае будут недоступны.
Возможно, мы по разному трактуем термины. Было бы проще, если были бы конкретные примеры этих решений. Эти решения можно использовать в связке с SPA, например на Angular?
Тестовость данного проекта очевидна. Все контейнеры сложены в один только в демонстрационных целях. Чтобы можно было одной командой развернуть и попробовать.
А с замечанием полностью согласен.
Спасибо за замечание. Порты наружу открыл в демонстрационных целях. Собственно, сервер и клиент открыты через nginx. Socket.io тоже получается нужно открывать наружу, иначе клиентский браузер к нему не достучится.
Про fastcgi согласен. Конфигурация у nginx далеко не образцовая. Цель была продемонстрировать возможность
Практически 100%. Цель была - настроить полностью автономный конвейер ИИ-агентов. Но не получилось. Где-то на 1/3-1/2 пути пришлось в ручном режиме управлять.
В time-travel много кода. С учетом количества и объема рефакторингов и покрытия тестами руками я бы это не сдюжил
Философия
— Zustand: одно хранилище, минимум абстракций. Быстро, просто, «меньше магии».
— Nexus State: состояние как сеть независимых атомов. Изоляция, явные зависимости, предсказуемость в сложных сценариях.
Код в примерах
О формах
— Zustand: удобно для простых форм. Легко сбросить всё состояние. Отлично дружит с
react-hook-form. Валидация — в логике компонента или через доп. поля.— Nexus State: каждое поле — отдельный атом. Обновление имени не триггерит ререндер email-поля. Идеально для динамических форм, кросс-валидаций, глубокой изоляции. Сериализация для SSR — встроенная (
store.extract()).Итог
— Выбираете скорость и простоту? → Zustand.
— Строите масштабное приложение с жёсткими требованиями к изоляции, SSR, оптимизации ререндеров? → Атомарный подход.
Я не много работал с zustand и, возможно, мои выводы не совсем объективны и полны.
В любом случае - спасибо за вопрос )
По поводу MobX дополню: в экосистеме есть инструменты вроде mobx-state-tree (сериализация,
flowдля асинхронки) и паттерны для ленивой загрузки, но вы правы — они требуют дополнительной настройки и не встроены «из коробки». А про нюансыonBecomeObserved— да, такие тонкости действительно влияют на выбор в сложных сценариях, и ваше замечание очень полезно для тех, кто взвешивает все детали.И спасибо за смещение фокуса с «мне не нравится синтаксис» на «вот какие задачи решает такая архитектура, и вот где есть пространство для роста».
Привет! Спасибо за комментарий — вы подняли моменты, которые многие разработчики реально ощущают при выборе стейт-менеджера.
Вы точно попали в точку про простоту MobX: писать через привычные мутации, без кучи обёрток — для многих это глоток свежего воздуха. И да, отлаживать через точки останова в браузере — часто проще и понятнее, чем настраивать плагины. Особенно когда команда уже «в теме» и знает, как работает реактивность. Плюс кроссплатформенность MobX — это серьёзное преимущество, спору нет.
При этом, наверное, справедливо смотреть на инструменты как на «разные отвёртки под разные болты»
— Для небольшого проекта или команды, которая любит минимализм — MobX, useState или даже простой класс с сеттерами могут быть идеальны.
— Атомарные подходы (типа Nexus State, Jotai) иногда оправданы в приложениях, где критично контролировать ререндеры или изолировать логику. Но вы правы: для счётчика писать store.set(countAtom, 5) — это явный перебор.
Главное — не абсолютизировать ни один подход. У каждого решения есть своя аудитория, свои задачи и компромиссы. Ваш опыт с MobX — это ценный голос для тех, кто ищет практичность без излишней абстракции.
Согласен. @ в пароле тоже "ломает" схему. Поправлю текст.
Что касается названия, то я сам искал настройку proxy в Ubuntu для WSL. И, видимо, поэтому название получилось несколько "зашоренным".
Согласен. Предлагаемый в статье подход подразумевает ручную замену значений в достаточно большом количестве мест. Предлагаемый вами подход представляется перспективным. Но не смог найти примеров и/или реализовать самостоятельно определение и использование нужных переменных окружения для настройки wget и curl в случае наличия спецсимволов в логине или пароле.
Спасибо за замечание. Это была опечатка. Исправлю. Написано ради кейса с @ в логине. В моем случае написанные ранее статьи не помогали, так как в результате следования им я получал отказ в авторизации.
Согласен. Наверное, написанное в статье подойдет и для Ubuntu. Но в моем случае, не было возможности проверить это. Поэтому указал, что для wsl.
А. Вы статью то и не читали. Извините за путаницу тогда. Ограничения на длину заголовка знаете ли.
Прям первый (первый, Карл) абзац
Так мы говорим про агентов или про запросы к АПИ?
И может быть получится найти хоть какой-нибудь пример в подтверждение?
Чтобы уж не морочить никому голову путаницей из терминов
Есть примеры кода или просто примеры приложений 1-го типа (без серверной части), где используются агенты?
Описанный в статье способ расширения функциональности — приложения. А конкретнее приложения 1-го типа (в терминологии документации). На каком этапе здесь могут быть использованы агенты или проявляется влияние особенностей их работы?
Какое отношение к статье имеет этот комментарий?
"Нормальные программисты", "Мля", "вы недоношенные"… А семки остались?
Конструктивно. Просто эталонная фраза для код-ревью. Надо записать.
Если данные не скопировать в образ и попытаться запустить его например на AWS, то некрасиво получится, так как они (данные) в этом случае будут недоступны.
Возможно, мы по разному трактуем термины. Было бы проще, если были бы конкретные примеры этих решений. Эти решения можно использовать в связке с SPA, например на Angular?
Тестовость данного проекта очевидна. Все контейнеры сложены в один только в демонстрационных целях. Чтобы можно было одной командой развернуть и попробовать.
А с замечанием полностью согласен.
Спасибо за предложение.
Внес изменения
Спасибо за замечание. Порты наружу открыл в демонстрационных целях. Собственно, сервер и клиент открыты через nginx. Socket.io тоже получается нужно открывать наружу, иначе клиентский браузер к нему не достучится.
Про fastcgi согласен. Конфигурация у nginx далеко не образцовая. Цель была продемонстрировать возможность