React keeping track of state in parent components?

JavaScript
#1

Hey guys, I’m currently on a problem that is bugging the absolute hell out of me. I can’t really share the code, but I can speak of the problem on a higher level in hopes one of you will be able to have me see this in another way.

First things first, we are using no state management.

We have a parent Products component that maps the Product components. Some of the products have Items (if they contain them) and pass as props down into each component. These Items are then mapped within the Product component to display. Each Item has a dropdown where you can select a user. The API is called within the Product component to retrieve the user’s information. Depending on a boolean flag on the user object from the API response, we toggle whether true or false on the Item that is displayed within the Product.

For example: a Product can have 2, 3, 10, etc. items, respectively with 2, 3, 10, etc. users.

After assigning all users to the product’s items and refreshing the page, the Items props from the Products (parent component) is properly updated and everything is wonderful. However, we all know I can’t rely on refreshing the page which is where my problem is.

How can I keep track of each assigned user’s flag? I would assume keeping track of an array of true/false for each number of user in the state, then populate that within the Items props? I know I need a useEffect() in the parent component most likely? I wouldn’t think I need a piece of state in the product because it has multiple Items. I’m not sure anymore and have really been spinning my wheels. Thanks.

#2

First things first, we are using no state management.

Yes you are, you’re just doing it manually.

How can I keep track of each assigned user’s flag? I would assume keeping track of an array of true/false for each number of user in the state, then populate that within the Items props?

OK. If I understand, you’re asking about storing the app state in the parent. Yep, without an external store, you kind of have to do that. You could also use context, but I’m guessing you’re not going down that road.

So you store the app state in your parent then pass whatever data you need to the children and whatever callbacks they need if they need to change that data. Those call backs might be a function that calls setState if it is a class, or the function setter returned by useState if it’s a FC. You could also go down the useReducer or make a custom hook. But those children need a function to call to change the app state, the one that is in the parent.

I know I need a useEffect() in the parent component most likely?

Not unless you are thinking of something else. We don’t need to run something on a dependency change (at least as to what you’ve described) so we wouldn’t need that, I think.

I wouldn’t think I need a piece of state in the product because it has multiple Items.

Why? State can be a simple number or it can be a massive object/array. It can be whatever you want. I think you’d want to divide it up where possible, but whatever you need to do, do it.

However, we all know I can’t rely on refreshing the page which is where my problem is.

I don’t understand this statement at all. Maybe this is related to your misunderstanding about useEffect. When in React do you need to “refresh the page”? The point of React is that you let React handle it. How does it figure out if it needs to rerender? If props or state have changed. If you’re updating state, it should take care of it. Unless you interfere with that with something like _shouldComponentUpdate, PureComponent, or the memo HOC.

If this is a simple project, then you can probably get away without something like redux, but if this project grows, the state management problems are going to grow exponentially.

#3

It is a massive project with many many people on it. When I meant state management, it is absolutely unruly without Redux or Context. Would you recommend I have a piece of state in the parent AND child? What would either be? I can’t think of another way to not have it be an array of the user’s boolean flags.

#4

Sure, you can keep separate states. For example at work we use redux, but sometimes a component may have it’s own state, if it’s something that only that component needs to know about. You have to make decisions about what is needed where. Is a central store good? Do you have different sections have their own store and/or certain children managing their own state? It really depends on the the project. One nice thing about redux is that it pulls all of that out of your components and it gets handled separately, each component just hooking in to what it needs. I’m not saying you always need something like redux, but as things grow, so does the need.

#5

Absolutely understandable and I have worked with Context and Redux as well. I think what is the most confusing about this problem is that you cannot set the state on when the items are mapped in the JSX. So that’s why I thought I need to set an array of booleans to keep track of that state and somehow map that state to the props.

#6

what is the most confusing about this problem is that you cannot set the state on when the items are mapped in the JSX

I don’t understand why you would need to. You’re JSX should be driven by state and props.

So that’s why I thought I need to set an array of booleans to keep track of that state …

Sure, that makes sense to me. I don’t know your exact implementation, but that is completely reasonable to keep that in state somewhere.

… and somehow map that state to the props.

I’m not sure I understand. It is state somewhere (if you want to to be), most likely in a common ancestor and is passed down as props to children. That is standard React. I don’t see what is difficult here. That is completely normal. But when it gets onerous, there are things like context or redux.

#7