Разделение ответственности (Чистая архитектура) при использовании React в сочетании с Redux

У меня проблема, и я недавно изучаю Чистая архитектура. То есть: Я знаю, что когда я захочу использовать Redux в React, мне придется сделать так:

ReactDOM.render(                 
   <React.StrictMode>               
       <Provider store = {store}>                   
            <App />               
       </Provider>           
   </React.StrictMode>,           
document.getElementById('root') )

а затем я использую useSelector и useDispatch (хуки) для выбора данных и отправки действия... в моих реагирующих компонентах. Но, я вижу проблему (на мой взгляд). Это мое приложение для реагирования тесно связано с этим инструментом управления состоянием (сокращение). Итак, если в будущем Redux устареет или я не хочу использовать redux, я хочу использовать Recoil, MobX или новые современные инструменты управления состоянием и т. д. Или, может быть, в моем приложении я хочу использовать redux в сочетании с другими (Recoil,...) для управления состоянием моего приложения. Итак, я хочу слабую связь между реакцией и сокращением.

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

Может ли кто-нибудь дать мне свежий взгляд на эту проблему?

PS: Мой английский не очень хорош. Я надеюсь, что все могут получить мою проблему? Большое спасибо.

Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Навигация по приложениям React: Исчерпывающее руководство по React Router
Навигация по приложениям React: Исчерпывающее руководство по React Router
React Router стала незаменимой библиотекой для создания одностраничных приложений с навигацией в React. В этой статье блога мы подробно рассмотрим...
Массив зависимостей в React
Массив зависимостей в React
Все о массиве Dependency и его связи с useEffect.
1
0
43
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

У меня был опыт работы с обоими основными менеджерами состояний React: Редукс и Мобкс, и я столкнулся с одним и тем же вопросом.

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

Реактивность Mobx работает иначе, чем в Redux.

Во-первых, вы столкнетесь с необходимостью обернуть ваши компоненты в функцию наблюдатель, которая добавит связи вашим компонентам. Кроме того, потребуются некоторые усилия для реорганизации ваших компонентов, чтобы сделать их совместимыми с Мобкс, потому что реактивность Мобкс зависит от разыменование значения. Вы можете прочитать об этом в документации Мобкс. https://mobx.js.org/understanding-reactivity.html

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

Единственный вариант, который я вижу, — разделить компоненты React на два типа:

  1. Контейнерный компонент. Вся логика управления состоянием идет сюда. Он получает фрагменты состояния приложения, запускает действия и передает реквизиты UI-компонентам.
  2. UI-компонент Компонент, который строит DOM-элементы. У него может быть собственное состояние, но в основном логика рендеринга основана на свойствах компонентов.

Это позволит вам снизить затраты на смену менеджера состояний в будущем, потому что вы сможете постепенно переписывать компоненты контейнера, не слишком беспокоясь о пользовательском интерфейсе.

Другие вопросы по теме