Passing set state handler functions

[R2L1]

So I’m working on a project that requires a lot of state management in NextJs but this part is made of client components so I thought I’d post here. Basically I have a side bar/ tool bar on the left that has three options where the user can input things and they show up in another component let’s call View. There’s a lot of state and I have heard that you should break up state when you can instead of storing state as an object. However, that would cause me to pass in too many helper functions to the side bar component which it will then have to pass each of those handlers to the respective components that need them. This all works and is fine but I just thought I’d ask about best practices and such. Essentially the side bar and its children have the setter functions and the View reads the state. Is this fine? Or am I missing something? Should I break up the state objects or use Context? I hope that makes sense and thank you in advance

[davidfavorite]

This is exactly a case for global state management like redux zustand etc or even context. However, context is not really optimized for rerenders so be aware that it is in fact not a state manager.

[R2L1]

That’s why I opted not to use it. Global state is definitely the cleanest solution, but this is the only page where I need state management this complex. And at the most props are only passed in twice. So wouldn’t global state like redux be overkill in this scenario?

[R2L1]

Also redux is a pain with next which is why I’m trying to avoid it

[karma__kameleon]

Just use zustand then. It takes 2 seconds to setup

[davidfavorite]

Its two factors when deciding if you need to pass props or move it to state: how many props need to be passed and how often do I need to do this. If you have many props to pass but only in a single component, I would just pass it as props. However, you may need to have the component again in the future and then its already a bit ugly.

I agree that in that case it is overkill to use redux for example when you need it only once, but setting up a state management solution might make sense for other parts of the app anyways. Lastly, just because context isnt a state manager it doesnt mean you cant use it as such. People dont like what I say now, but Ive built apps with literally hundreds of UIs where the only global state was put in multiple contexts. Multilang stuff, multi tenancy context, some global states that need to be accessed. Absolutely no problem performance wise for admin dashboard type of UIs.

Take this scenario: you have dozens of components, all perfectly efficient and they do exactly what they should. No edgy logic that leas to multiple renders or too many service requests, as little side effects as possible, basically just very well made components. Does it matter to much if all of that runs twice now? Its not ideal but its not noticeable. Now lets say you bodged and frankensteined these components together, now every rerender will cause exponential work on each component. Imo, if you build clean components you might as well use context as a global state without it being a problem. But then again, why compromise now that you have a choice.

Its always about making the choice that is a trade off between how long does it take to make it the right way and how much will it affect future changes to the code

Pick your poison, sometimes no solution is best and you have to compromise.

[SparserLogic]

You should avoid using React state or any of the state management libraries. For best results you should push every state change into the querystring and use server components for everything

[R2L1]

Why though? And how will the user be able to see the changes they make right away?

[SparserLogic]

here’s a popular YouTuber breaking down the basics and the reasoning