Без ограничений 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 значение пропом?
Одно из главных отличий FSD от вашей архитектуры как раз то, что FSD старается оперировать бизнес сущностями, а все остальное лежит shared. Ну и как подметили ребята в комментариях FSD это больше методология, которая не может четко описать то, как все должно лежать
А это не он матерится, а ИИшка, которая написала за него статью!
Хорошая статья с хорошей библиотекой!
Пользуюсь и иногда опенсоршу (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 значение пропом?
Очень крутая история, спасибо большое за статью, было интересно читать)
Одно из главных отличий FSD от вашей архитектуры как раз то, что FSD старается оперировать бизнес сущностями, а все остальное лежит shared. Ну и как подметили ребята в комментариях FSD это больше методология, которая не может четко описать то, как все должно лежать