ReactJS Где хранить state статуса модального окна(Как правильно, чтобы не был говнокод)?

Question

[gomerIT]

При нажатии на кнопку нужно открывать модальное окно. Я придерживаюсь разделение бизнес-логики и презентационных компонентов, а так же Flux архитектуре.
У меня есть глупые компоненты: Button, Modal, App.
Умный компонент: ModalContainer

ModalContainer:

import React, { useState } from 'react';
import Modal from '../components/Modal/Modal';
function ModalContainer() {
  const [modalActive, setModalActive] = useState(false);
  return <Modal active={modalActive} />;
}
export default ModalContainer;

Button:

function Button() {
  return <button type="submit">Кнопка</button>
}

App:

function App() {
  тут компоненты и т п...
  <Button />
  <ModalContainer />
}

Я думаю лучше создать умный компонент всего приложения AppContainer и там хранить state модального окна, и там же хранить функцию для изменения state и через props передавать в кнопку функцию. Т.е я представляю так:

function AppContainer() {
const [modalActive, setModalActive] = useState(false);
const modalChange = (status) => setModalActive(!status);

return (
  <App>
      <Button setModal={modalChange} />
      <Modal status={modalActive} />
  </App>
);
}

Как вы считается мое рассуждение правильное или это неправильно по логике Flux и стоит создать отдельный файл action импортировать его в AppContainer и так же пропсами передать функцию в кнопку?

Comments

[n1ksON]

В целом решение логичное, как мне кажется, правильное. Но я бы всё-таки написал это в компоненте ModalContainer. Зачем лишние компоненты просто так клепать...
Тоже считаю, что не стоит ради одной модалки целый actionCreator делать.
Но посмотрим, что асы скажут

Answer 1

[Виктор Дубров]

Хорошо, что вы задались этим вопросом!Вы думаете в верном направлении.
Начнем с того, что держать state в main компоненте, плохая практика, при его изменении будет происходить перерендер всех дочерних компонентов по умолчанию и вам придется подтирать за собой - сравнивая пропсы,
там где это не нужно и где вы даже ничего не принимаете (например в любых контейнерах).
Для этого есть store, той самой flux архитектуры которой вы пользуетесь. С этим мы поняли, да.

Далее нужно определиться, что вообще у вас за модальное окно?

Если оно у вас по типу - что-бы что-то сделать в приложении зарегистрируйтесь, и вылетает модалка , куда бы не нажали. То переиспользовать его уже становится бессмысленным, оно должно быть одно на верхнем уровне, так как это уже глобальное представление, а не плодить кучу в каждом компоненте, где есть обработка любых событий связанных с функционалом приложения напрямую. Тем более что ваш компонент, в таком случае с филосовской точки зрения , ничего не знает ни про какие модальные окна и знать не хочет, он отвечает за представление самого-себя любимого.
Поэтому вы решаете засунуть в store - reducer modalWindow с значением - show : false/true и диспачите экшен из любого компонента если нужно показывать/скрывать его.
Повторюсь в данном кейсе модальное окно ОДНО логически их не может быть куча, тем более, что конкретно к компонентам оно никакого отношения не имеет.

Если оно имеет прямое отношение к вашему компоненту вы хотите и можете его переиспользовать, меняя текст и прочую чепуху, прокидывая true/false и callback через пропсы, храня их в состоянии компонента, к которому это все относится. Но чаще всего это даже не модальные окна, а подсказки которые показывают дополнительную информацию, связанную с компонентом.

Если это алерты по типу - success, warning, error, которые вылетают где-то внизу (например ) в углу,
Вы могли бы их также переиспользовать, до момента пока пользователь не нажмет сразу же на эту/другую кнопку и не получит новое сообщение до того как пропало прежнее, и тут вам снова нужно выносить список алертов, которые в настоящее время активны в store, и складывать их в список в том же углу, удаляя и добавляя их, чтобы пользователь успевал читать, что именно ему "кричат".

Всегда думайте , нужно ли то что я пишу здесь, или может оно должно быть в другом месте.
С одной стороны создается впечатление, что создав state в main компоненте вы облегчите долю приложения, вместо того чтобы создавать лишний reducer, но как показывает практика это не так.

Answer 2

[Kirill Makarov]

Лично я бы создал модалку внутри неё хранил state и setState, затем где надо её использовать пропсом кидаю состояние true false, в модалке принимаю и если есть необходимость то меняю его через setState ну или функцию при необходимости. На мой взгляд нормальная практика