Альтернатива подъема состояния для вызова методов из других компонентов
Я разрабатываю мобильное приложение с помощью React-Native (кстати, я впервые использую React), и у меня возникают проблемы со связью между компонентами.
Насколько я понимаю, реакция предназначена для работы от родителей к детям через реквизит. Каждый компонент обновляет себя через свое состояние, а родитель — через обработчики, привязанные к свойствам. Тем не менее это не кажется правильным.
Parent (wrapper) component
|
|--AppBar Component
|
|--ListScrollView Component (displays API data fetched from the Parent)
|
|--FABmenu Component (handles the secondary components and provides callbacks to the Parent)
|
|--more secondary components (activity indicator, search bar, filtering modal etc)
Я реализовал это, поместив всю бизнес-логику в родительский компонент и передав родительские методы в качестве реквизита дочерним, но эта настройка оказывается хаотичной в моем случае использования, поскольку новые функции добавляются ежедневно, и мне нужно вернуться и вперед между компонентами, чтобы все работало.
Redux/Flux на самом деле не предоставляют решения для этого, они просто переопределяют это поведение с помощью глобального состояния, для которого вам нужно написать больше кода (подписки) для обновления отдельных компонентов.
Ссылки не раскрывают весь компонент, а только элементы, так что это тоже не вариант.
Я не знаю о вас, но это делает мой рабочий процесс чрезвычайно медленным, я бы предпочел писать методы для компонента, которому они (рационально) принадлежат, и вызывать их статически. Я что-то упустил или это грустная правда?
Редактировать: поскольку я использую expo, которая не поставляется с последними версиями react/react-native, я не могу в полной мере воспользоваться последними функциями (например, Context API). Немного повозившись, я решил использовать MobX, похоже, это помогло.
@go_diego, черт возьми, я не должен пропускать эту часть документации. Хотя это решает мою насущную проблему, Context является скорее обходным путем, поэтому я также переделаю свою структуру. Пока мы говорим, возвращаемся к доске. Спасибо всем за ваши ответы.
Ответы 2
Это не абсолютное правило, что вы должны поднимать состояние до родительского компонента верхнего уровня. Вы должны поднимать состояние как можно выше, чтобы не повторять действия несколько раз.
Например, если вы используете компонент Navbar, который должен отображать полное имя пользователя, вы должны выполнить выборку API для этих данных. Но, скажем, когда вы выбираете маршрут настроек, вам также нужно полное имя пользователя. Имеет ли смысл дважды обращаться к API? Один раз в панели навигации и один раз в компоненте «Настройки»? Возможно нет!
Но вы, как архитектор вашего приложения, отвечаете за признание этих возможностей и улучшение состояния там, где вы можете, но это не является абсолютным с React. Это рекомендация. Если вы обнаружите, что делаете тонну ненужной «сантехники пропсов» (т. е. передаете пропсы на шесть уровней компонентов ниже, когда в этом нуждается только один компонент), вы, возможно, подняли его слишком высоко.
Насколько мне известно, в архитектуре React нет ничего, что заставляло бы вас делать это. Такие решения, как Redux, могут помочь, как вы сказали, управлять потоком данных и иметь «глобальное состояние», но они не являются конечными и НЕ должны заменять локальное состояние. Есть еще много случаев и много возможностей иметь бизнес-логику внутри ваших компонентов.
Если это решение подходит вам и вашему приложению, действуйте.
Я бы посоветовал вам пройтись по некоторым базовым конструкциям написания приложения в React. Лично мне нравится Container => Component способ организации моего приложения.
Интеграция Redux, Router и т. д. — утомительные вещи в React.
Я следил за этим мастерская.
Кроме того, следите за этим блогом от Дэн Абрамов
Если вы обнаружите, что занимаетесь бурением реквизита, Контекстный API может навести здесь порядок.