Какой лучше? Хз. Попробуй все, потом нам расскажешь

Какой с точки зрения архитектурной чистоты будет лучше или так скажем "не костыль"

Все знают, что лучше последний, но он слишком трудно реализуем. Первый худший, но самый легкий и часто реализуемый

2 и 3 хуже, чем 1 и 2

Мне кажется ты просто ищешь совет где тебе скажут примени doSomething() и все заработает

2 хуже потому, что порождает неявные зависимости, -- чтобы были явными, надо юзать 4. 3 хуже потому, что создаёт непонятный поток данных и лишние рендеры 1 лучше потому, что общепринят. 4 лучше потому, что самый расширяемый и оптимизированный

По сути скорее всего так..

а кто так не хочет?)) makeProjectAndEarnOneMillionDollarsInSecond() и готово

Спасибо за объяснение ❤️

в твоем случае, самый легкиц способ - первый. второй и третий костыли чисто чтобы заработало и постепенно проект утонул в бездне

Ну это бог с ним, меня уже другие мысли волнуют. У меня же не единственного такой кейс появился где компоненты на одном уровне, а данные как то передать красиво надо. Другие также голову ломают и варианты перебирают или юзают архитектурное решение которое предотвращает такие ситуации? Тут наверно ответ про модуль будет или ещё что-то?

Основная проблема твоего проекта -- использование хуков для получения данных

Все над этим голову ломают

React-query и rtk-query в топку?

Да, собачье дерьмо Вообще, твоя проблема максимально легко решается контекстом для передачи пропсов по всему дереву, и созданием отдельного хука для запроса на уровне модуля, который берёт эти пропсы из контекста и юзает

тебе бы какую-то модельку, класс там такой, он своими делами занимается, данными, преобразованием их и всякое такое интересное.. а потом ты с ним в рескте как-то взаимодействуешь, его там улучшаешь постоянно, кеши там все такое.. типичный мвц знаешь, тока с особенностями

Условно, features/my-feature/model const Context = createContext<MyProps | null>(null) export const useMyQuery = () => { const props = useContext(Context) if (!props) { throw new Error(...) } return useQuery(...) } features/my-feature/ui const MyComponent1 = () => { const { data } = useMyQuery() .... } const MyComponent2 = () => { const { data } = useMyQuery() ... } export const MyFeature = { Wrapper: Context.Provider, MyComponent1, MyComponent2, } ...ну и юзаешь потом... <MyFeature.Wrapper> <MyFeature.MyComponent1 /> <MyFeature.MyComponent2 />

А как на счет создавать контекст для модели, чтоб не пропсами кидаться, а через него? Имеет место быть? (создаются на уровне страниц)

Бл, меня одного напрягает что для передачи данных по всему дереву я использую редакс, но из за фич его квери я должен ещё раз собственный провайдер лепить чтобы получить его же функционал

а зачем тебе контекст для модели? ты же просто лишнюю оболочку создашь и все

Это не его же функционал, ты ведь просто пытаешься устранить проп дриллинг. Вообще это очень зависит от того как у тебя конкретно приложение построено. Может быть есть и более подходящие способы в контексте твоего стека

Неявность тоже порождает, если сделать неправильно. Тут всё упирается в границы модулей и в их интерфейс. Я считаю, что контекст не должен быть их интерфейсом -- он может быть лишь внутренней реализацией. Интерфейсом же должна быть явная передача через пропсы Иногда имхо можно делать компаунды, но тогда нужно упарываться в нормальное документирование анатомии. Но компаунды сложнее рефакторить, потому что эта самая анатомия может быть размазана по всему модулю-консьюмеру, и чтобы понять как и что там юзается, надо будет изучать как именно этот консьюмер работает

Условно export const MyFeatureEntrypoint = ({ model, ...ui props }) => ( <MyFeatureModelContext.Provider value={model}> <MyFeatureComponent1 /> <MyFeatureComponent2 /> </ MyFeatureModelContext.Provider> ) const MyFeatureComponent1 = () => { const model = useContext(MyFeatureModelContext) ........do something with the model.......... }

Но мы проп-дриллим модель обычно, не юзаем контексты

Потому что очень легко потерять где у тебя там энтрипоинт а где нет. Если у фичи становится несколько энтрипоинтов (т.е. просто компонентов, которые экспортируются), то очень легко потерять где-то этот самый контекст, и никакой статический анализатор тебе не покажет ошибку -- увидишь только когда запустишь код