Reputation: 69
Let's assume I have a parent App
component, which keeps user settings saved in it's state and synced throughout my app, by being passed down as a Settings
object to all of it's children.
And for sake of the argument, Let's assume App
has two other child components, one called Settings
component, which holds a form, where the user inputs his/her settings and clicks submit to submit it's settings.
And another Foo
component which projects/shows/hides various elements or other components based on the settings the user selected for the app in the earlier form.
Those two components won't render together, only once the user submits the form the Foo
component is displayed.
Now I find myself tangled between two approaches: one, is to keep all settings also in a state saved inside my Settings
component, and each time an input changes, update only the Settings
's component state accordingly, by having an handler for each input, and pass all those settings to the App
component via a callback (which will update App
's state) only once the user submits the form.
Or, make Settings
a stateless component, and pass all input handlers as callbacks (or as one unified callback) to the App
component, which will then update the state on every input change.
As an old-school web developer, I prefer the first approach as it updated the App
component only once, and so it re-renders all of it child components also only once, and yet my Settings
component remains independent to the App
component, and their only interface is the OnSubmit
callback which passes the whole settings object once.
The second approach, on the other hand, separates all logic and handling from the Settings
component, removes redundant states, and leaves it as a plain and simple UI "view" component if you will. And looks like the common design pattern used in many React apps I've seen.
Which approach is better and why? Is there anything else I'm missing out? How would you go by handling this? What is the best practice for parent-child interactions in React? How much would you want your child component to be encapsulated and independent from it's environment? And how many callbacks would you want to pass along from parent to child?
I would also really appreciate some good references and reading materials..
Thanks.
Upvotes: 5
Views: 3677
Reputation: 1336
State at top level component and stateless child components is always preferred in React.
Regarding callbacks, passing the 'relevant' ones down is again preferred. What is many very subjective. But readability must be the top most and 'callback' relevance to the child component.
In our large codebase, we have only 3 callbacks maximum and not more than 2 levels of nesting from the top most component. We have extensively used ES6 destructuring, Immutability Helpers, triple dot ... operator to manage the state at the top component (on receiving data from children) and keep all the children as stateless components.
This has helped us in improving tests and have a high coverage on the components as well. Easier to read and better performing components are definite results from stateless components.
If you have components that need 'events' to be passed down and not state (data), or if your nested levels are going beyond 2 and code is unmanageable then you have to explore state management frameworks like Redux (ex.,).
Thanks, Sriram
Upvotes: 2
Reputation: 11515
I recommend using a flux pattern, You can put your state into data stores and allows components to share data and also watch for changes, this will avoid an explosion of handlers and props cascading down the hierarchy.
Upvotes: 0
Reputation: 3346
This question is very broad, and you need to provide at least a MVP to get some practical answers on this. You can't go wrong with official documentation:
Upvotes: 0