решение:
Есть страница-список элементов (Main), по нажатию на элемент открывается страница с детальным описанием (Details); при определённом условии можно эти детали редактировать (отдельный экран EditDetails).
То есть, схема такая: Main -> Details -> EditDetails
На странице EditDetails есть кнопка удаления. Мне нужно вернуть из EditDetails id в Main.
Можно сделать navigation.pop(2), но я не смогу таким образом передать значение.
Можно передавать функцию для удаления из Main вниз до EditDetails, но из-за структуры компонентов мне придётся пробрасывать сначала в один компонент, потом из него при переходе в Details, оттуда при переходе ещё раз в EditDetails. Много лишней возни и не хочется плодить лишнюю логику там, где она явно избыточна. Есть ещё варианты такое сделать?
UPD: попробовал пробрасывать через пропсы, не работает, в конечной странице вместо функции просто undefined.
Попробуй контекст апи юзать.
решение - использовать стейт-менеджер (redux/mobx/effector) для хранения данных и работы с ними. в этом случае всё сводится к передаче между экранами заранее известного id, остальные операции с данными - вызовы на конкретных экранах методов, которые работают непосредственно с стМ контекст с общим стейтом родителя, конечно, тоже можно использовать, но в этом случае можно в какой-то момент прийти к зоопарку решений. ну и вот это стоит глянуть, для осознанного выбора https://gist.github.com/XaveScor/99431c573b53b8a0c41fb3b5fec522bc
Можно использовать popToMain, если компонент Main самый первый в стеке.
Не, в приложении redux есть, но массив данных в него пихать нет смысла. Ну id можно через redux, конечно, но это какой-то оверкилл
Я могу и pop(2) сделать, но данные все равно передать надо.
У тебя проблема в том, что бизнеслогика живет в графических компонентах - Сделай кастомный хук - В хук передай функцию, которая получает имя экрана, и переходит на него - стэйт приложения храни в этом хуке - всю логику реализуй в хуке - из хука верни интерфейс из колбэков и стэйта, который легко будет отобразить графическими компонентами - этот интерфейс положи в контекст Теперь в графических компонентах ты сможешь доставать этот интерфейс из контекста Чтобы связать интерфейс с граф компонентом создай промежуточные компоненты
так а в чём отличие (и главное, преимущества) этого решения от использования стм (в данном случае redux) для хранения данных (ну, не считая того что это "не redux") ?
а что это за массив данных, которые не имеет смысла пихать в стм ?
Никакого, но это не redux - огромный плюс )
только это и не стм что еще больший минус
ну если я правильно понял совет был про реакт контекст?
Обсуждают сегодня