Так и не понял зачем нужно было уходить от MobX, если можно было заюзать одну из опенсорс либ интеграции MobX с tanstack query (например mobx-tanstack-query).
В итоге уйдя от МобХ вы будете прибивать бизнес логику к механизмам рендеринга , тем самым подшивать бизнес логику в слой представления.
Получается три одинаковых вызова хука и изменение в одном из компонентов не последует обновлению в тех местах где есть обращение к ключу стораджа через этот хук?
Если это так, тогда зачем нужен этот не стабильно работающий хук, если он будет выдавать не актуальное состояние из стораджа.
Как только люди не пытаются возиться с реактом, лишь бы не использовать стейт менеджеры
Без ограничений React экосистемы (можем ли мы под условиями запускать хуки? Можем ли мы одноразово вызывать сложные вычисления ? Можем, но при помощи хуков, но хуки у нас вызываются на каждом рендере (useMemo, useEffect, useState)
у нас нет привычной возни с контекстом.
Да, тут согласен, только теперь у нас есть возня с хуками
Вот есть функция Component, которая вызывает ещё функции use*, которые вызывают ещё функции useHook, внутри которых вызываются ещё другие функции useHookN…
Был один такой рабочий проект, где у нас на клик кнопки сервер возвращал 2х мегабайтный JSON, который полностью перерисовал всю страницу, а если раз 10 эту кнопку понажимать))
В общем мое мнение - такой подход может подойти для каких нибудь простых/типичных экранов
Брать в 2025 году Redux как стейт менеджер зачем? Зачем нужны эти палки в колёса? Очень много раз уже обговаривалось огромное количество проблем и трудностей в разработке, которые даёт Redux
mobx есть пять взаимозаменяемых способов диспатчить action creator’ы.
Нет такого в MobX, на MobX можно написать Redux, возможно этого и пытались добиться созданием action creator`ов
Как правило в реакт проектах ребята просто раскладывают компоненты слайсы фичи утилиты и все прочее в рандомные папки, а с FSD хоть какой то полупорядок будет.
Прошёл все виды вёрстки от pug / CSS , CSS in JS , bem, postcss , для себя решил что tailwind хорош во всем кроме специфичных селекторов из за которых классы превращаются действительно в кашу
tsrynge нельзя подружить с accessor декораторами, отсюда и множество проблем, что с этой библиотекой разработчики будут вынуждены использовать legacy декораторы.
Подскажите пожалуйста, могу ошибаться, разве в вашем примере с useDeferredValue хуком при изменении состояния не произойдет ререндер как компонента, который содержит стейт поиска, так и дочерний компонент, куда передаётся deffered значение пропом?
Ждём появления новых крутых хуков из разряда
useVercelPerfBoost(API_TOKEN)
useCallstackServerState()
Так и не понял зачем нужно было уходить от MobX, если можно было заюзать одну из опенсорс либ интеграции MobX с tanstack query (например mobx-tanstack-query).
В итоге уйдя от МобХ вы будете прибивать бизнес логику к механизмам рендеринга , тем самым подшивать бизнес логику в слой представления.
Хорошо, зайдём на огонёк)
Получается три одинаковых вызова хука и изменение в одном из компонентов не последует обновлению в тех местах где есть обращение к ключу стораджа через этот хук?
Если это так, тогда зачем нужен этот не стабильно работающий хук, если он будет выдавать не актуальное состояние из стораджа.
Как только люди не пытаются возиться с реактом, лишь бы не использовать стейт менеджеры
А это не он матерится, а ИИшка, которая написала за него статью!
Хорошая статья с хорошей библиотекой!
Пользуюсь и иногда опенсоршу (gravity-ui)
Спасибо большое за такую крутую и полезную статью!
Давно думал на тему внедрения IoC в рабочие проекты на MobX, но все никак не доходят руки.
Интересно, а как работает HMR при таком подходе ?
Только без префиксов use
Без ограничений React экосистемы (можем ли мы под условиями запускать хуки? Можем ли мы одноразово вызывать сложные вычисления ? Можем, но при помощи хуков, но хуки у нас вызываются на каждом рендере (useMemo, useEffect, useState)
Да, тут согласен, только теперь у нас есть возня с хуками
Вот есть функция Component, которая вызывает ещё функции use*, которые вызывают ещё функции useHook, внутри которых вызываются ещё другие функции useHookN…
Смею предположить, что основная причина отказа от классов было нежелание изучать и/или внедрять ООП подход
Был один такой рабочий проект, где у нас на клик кнопки сервер возвращал 2х мегабайтный JSON, который полностью перерисовал всю страницу, а если раз 10 эту кнопку понажимать))
В общем мое мнение - такой подход может подойти для каких нибудь простых/типичных экранов
Брать в 2025 году Redux как стейт менеджер зачем? Зачем нужны эти палки в колёса? Очень много раз уже обговаривалось огромное количество проблем и трудностей в разработке, которые даёт Redux
Нет такого в MobX, на MobX можно написать Redux, возможно этого и пытались добиться созданием action creator`ов
Я бы сказал так - лучше с FSD чем без него)
Как правило в реакт проектах ребята просто раскладывают компоненты слайсы фичи утилиты и все прочее в рандомные папки, а с FSD хоть какой то полупорядок будет.
А чем FSD лучше DDD ?
Прошёл все виды вёрстки от pug / CSS , CSS in JS , bem, postcss , для себя решил что tailwind хорош во всем кроме специфичных селекторов из за которых классы превращаются действительно в кашу
Ну а я работаю в 9 крупных проектах Которые живут в айфреме и все на тейлвинде. Удобно, быстро, легко и никаких проблем не испытываю.
tsrynge нельзя подружить с accessor декораторами, отсюда и множество проблем, что с этой библиотекой разработчики будут вынуждены использовать legacy декораторы.
Больше возникает вопрос - почему хранение бизнес логики приложения в слое предоставления правильное решение и почему команда React тоже так считает?
Почему это считается правильным только во фронтенд веба ?)
Подскажите пожалуйста, могу ошибаться, разве в вашем примере с useDeferredValue хуком при изменении состояния не произойдет ререндер как компонента, который содержит стейт поиска, так и дочерний компонент, куда передаётся deffered значение пропом?
Очень крутая история, спасибо большое за статью, было интересно читать)