G
G
gomerIT2020-12-26 21:20:06
React
gomerIT, 2020-12-26 21:20:06

ReactJS Where to store the state of the status of the modal window (What is the right way so that there is no shitty code)?

When you click on the button, you need to open a modal window. I adhere to the separation of business logic and presentational components, as well as the Flux architecture.
I have stupid components: Button, Modal, App.
Smart Component: ModalContainer

modal container:

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 />
}

I think it's better to create a smart component of the entire AppContainer application and store the state of the modal window there, and store the function for changing the state there and pass the function to the button through props. That is, I present it like this:
function AppContainer() {
const [modalActive, setModalActive] = useState(false);
const modalChange = (status) => setModalActive(!status);

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

Do you think my reasoning is correct or is it wrong according to the Flux logic and is it worth creating a separate action file, importing it into the AppContainer and passing the function to the button as props?

Answer the question

In order to leave comments, you need to log in

2 answer(s)
V
Viktor Dubrov, 2020-12-27
@victor1985

It's good that you asked this question! You are thinking in the right direction.
Let's start with the fact that keeping the state in the main component is a bad practice, when it changes, all child components will be re-rendered by default and you will have to wipe up after yourself - comparing props
where it is not needed and where you do not even accept anything (for example, in any container).
There is a store for this, the same flux architecture that you use. With that, we got it, yes.
Next, you need to decide what kind of modal window you have in general?
If it is your type - to do something in the application, register, and the modal takes off, wherever you click. Then reusing it already becomes meaningless, it should be one at the top level, since this is already a global view, and not produce a bunch in each component, where there is a processing of any events related to the application functionality directly. Moreover, your component, in this case, from a philosophical point of view, does not know anything about any modal windows and does not want to know, it is responsible for presenting itself beloved.
So you decide to put in a store - reducer modalWindow with the value - show : false/true and dispatch the action from any component if you want to show/hide it.
I repeat in this case, the modal window ONE logically cannot be a bunch of them, especially since it has nothing to do with the components specifically.
If it's directly related to your component, you want to and can reuse it, changing the text and other nonsense, passing true/false and callback through props, storing them in the state of the component to which it all applies. But most often these are not even modal windows, but tooltips that show additional information related to the component.
If these are alerts of the type - success, warning, error, which fly out somewhere below (for example) in the corner,
You could also reuse them, until the user immediately clicks on this / another button and receives a new message before the old one is gone, and here again you need to list the alerts that are currently active in the store, and add them to the list in the same corner, deleting and adding them so that the user has time to read what exactly they are "shouting" to him.
Always consider whether what I write here is necessary, or maybe it should be in another place.
On the one hand, it seems that by creating state in the main component, you will lighten the share of the application, instead of creating an extra reducer, but as practice shows, this is not the case.

K
Kirill Makarov, 2020-12-27
@kirbi1996

Personally, I would create a modal inside it, store state and setState, then where it is necessary to use it with a prop, I throw the true false state, accept it in the modal and, if necessary, change it through setState or a function if necessary. Normal practice in my opinion.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question