Мы решились на сразу несколько экспериментов - новый фреймворк (Tramvai), FSD, react-query. И в рамках Tramvai решили попробовать fsr - для себя условились, что routes - будет нашим слоем pages. Вы верно подметили и про Steiger(да - хочется его подключить в будущем) и про то, что иногда приходится создавать вложенные папки для сложных роутов. В целом это нам не помешало и структура FSD сложилась. Tramvai позволяет реализовать не только fsr реализовать - и, возможно, в следующих проектах мы от него откажемся (вопрос открыт)
Хуки в useEffect не вызываются. Не силен в нэйтив - но как я понял из контекста вопроса - ремаунта компонента при свайпе не будет (а значит и вызова useQuery повторно), но есть необходимость заново получить данные серверва. Если в момент свайпа и показа его что то меняется (хз - индекс показываемого стэка или еще чтото) - то можно его прописать в ключи квери - queryKey: ['updateSomeServerDataKey', index], тогда с каждым новым index (точнее с изменением) - квери апдейтнется
Соглашусь - можно написать хук для чего угодно, можно много чего написать самостоятельно. Но тут мы можем влететь в проблему масштабирования команды - когда приходят новые разработчики на проект, где много чего написано самостоятельно, время "вкатывания" повышается, особенно, если написавшие не оставили документации и уволились с компании... Опять же - ваш подход также рабочий
Мы сейчас очень стараемся как раз таки структурно все реализовать так - чтобы смешивания не было - как пример вдохновлялись вот этой статьей . Все технологии (fsd, rq, tramvai), мы обкатали на новом проекте, который сейчас уже в статусе "эксплуатация" - и команда признает положительный опыт - разделение по слоям и сегментам позволяет не замешивать все в одном компоненте, бойлерплэйта минимум
или Effector, или - да в целом выбор то богатый. Про это напишу заметку - о том что выбрали, и какие плюсы / минусы были найдены. Про RC я упомянул - потому что захотелось внимательнее оценить использование общего клиентского стэйта - если его будет мало - может и не стоит оно того- чтобы тащить еще один стейт менеджер
Есть такое да - но там мы столкнулись и с другими трудностями fsr - потому с дальнейшим его использованием - еще не определились
Мы решились на сразу несколько экспериментов - новый фреймворк (Tramvai), FSD, react-query. И в рамках Tramvai решили попробовать fsr - для себя условились, что routes - будет нашим слоем pages. Вы верно подметили и про Steiger(да - хочется его подключить в будущем) и про то, что иногда приходится создавать вложенные папки для сложных роутов. В целом это нам не помешало и структура FSD сложилась. Tramvai позволяет реализовать не только fsr реализовать - и, возможно, в следующих проектах мы от него откажемся (вопрос открыт)
Хуки в useEffect не вызываются. Не силен в нэйтив - но как я понял из контекста вопроса - ремаунта компонента при свайпе не будет (а значит и вызова useQuery повторно), но есть необходимость заново получить данные серверва. Если в момент свайпа и показа его что то меняется (хз - индекс показываемого стэка или еще чтото) - то можно его прописать в ключи квери - queryKey: ['updateSomeServerDataKey', index], тогда с каждым новым index (точнее с изменением) - квери апдейтнется
Соглашусь - можно написать хук для чего угодно, можно много чего написать самостоятельно. Но тут мы можем влететь в проблему масштабирования команды - когда приходят новые разработчики на проект, где много чего написано самостоятельно, время "вкатывания" повышается, особенно, если написавшие не оставили документации и уволились с компании... Опять же - ваш подход также рабочий
Мы сейчас очень стараемся как раз таки структурно все реализовать так - чтобы смешивания не было - как пример вдохновлялись вот этой статьей . Все технологии (fsd, rq, tramvai), мы обкатали на новом проекте, который сейчас уже в статусе "эксплуатация" - и команда признает положительный опыт - разделение по слоям и сегментам позволяет не замешивать все в одном компоненте, бойлерплэйта минимум
Возможно он и заедет - НО - есть большой план уехать на Tramvai (мотивация и прочее - отдельной заметкой) - а там есть свой стэйт менеджер для клиента
для мутации данных на сервере - есть https://tanstack.com/query/v4/docs/framework/react/guides/mutations (если я верно вопрос понял) При мутации - можно также отображать процесс отправки запроса (условный лоадер) - или не отображать сделав optimistic update
или Effector, или - да в целом выбор то богатый. Про это напишу заметку - о том что выбрали, и какие плюсы / минусы были найдены. Про RC я упомянул - потому что захотелось внимательнее оценить использование общего клиентского стэйта - если его будет мало - может и не стоит оно того- чтобы тащить еще один стейт менеджер