И эта архитектурная методология, которая накладывает тоже определённые ограничения, также как и FSD, будет вызывать много споров и вопросов.
Читая данную статью, у меня возник вопрос по поводу роутеров. Если импорты между pages и из app запрещены, тогда как пользоваться атомарным роутами во фронтенд приложениях?
Данный роут, обычно я размещаю на уровне pages/products чтобы он лежал в том месте, к чему он относится. Соответственно, чтобы навигироваться то нужно этот роут импортировать, а по правилам FEOD нужно конфигурацию прутов выносить в global , или же в app/routing (но при этом нельзя оттуда импортировать)
Как раз таки наоборот, реакт компоненты перерендериваются почти на каждый чих. Конечно если оборачивать компоненты в observer из MobX или memo из React то такого не будет
Недавний реакт конф показал что сигналы это не серебряная пуля и не мана небесная, конечно непонятно какие разрабы реакта имели в виду сигналы.
Уменьшить количество ререндеров и добиться гранулярных ререндеров можно добиться и так с помощью MobX, до сих пор не понимаю почему люди так боятся этой библиотеки, что вновь и вноаь изобретают что то )
Так и не понял зачем нужно было уходить от 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 декораторы.
И эта архитектурная методология, которая накладывает тоже определённые ограничения, также как и FSD, будет вызывать много споров и вопросов.
Читая данную статью, у меня возник вопрос по поводу роутеров. Если импорты между pages и из app запрещены, тогда как пользоваться атомарным роутами во фронтенд приложениях?
Пример:
Данный роут, обычно я размещаю на уровне pages/products чтобы он лежал в том месте, к чему он относится. Соответственно, чтобы навигироваться то нужно этот роут импортировать, а по правилам FEOD нужно конфигурацию прутов выносить в global , или же в app/routing (но при этом нельзя оттуда импортировать)
Как раз таки наоборот, реакт компоненты перерендериваются почти на каждый чих.
Конечно если оборачивать компоненты в observer из MobX или memo из React то такого не будет
Недавний реакт конф показал что сигналы это не серебряная пуля и не мана небесная, конечно непонятно какие разрабы реакта имели в виду сигналы.
Уменьшить количество ререндеров и добиться гранулярных ререндеров можно добиться и так с помощью MobX, до сих пор не понимаю почему люди так боятся этой библиотеки, что вновь и вноаь изобретают что то )
Ждём появления новых крутых хуков из разряда
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 декораторы.