Jammming project - stateless child components?

Get Help React.js
#1

Hi,

This is more of a query than a request for help. In the Jammming project solution, it shows the SearchBar component creating its own state to hold the search term that the user enters.

Is this a common pattern? Because I thought the previous React lessons suggested only ever holding state in the parent component, i.e. in App.js.

Everything else so far in the project has involved setting and updating the state in App.js, so I was expecting the SearchBar to follow the same pattern - create a method in App.js to update the state there with the search term, and pass that method down as a prop.

#2

Yes, it is fairly common to keep it in the same component if the state does not need to be shared with other components. Especially now with hooks there is minimal code involved. So for something like an input-field you can keep the state in the component and then send the value somewhere on “submit” (to Redux Store or an API for example).

The main reason for moving the state “up” is to share it with other components due to the one-way data flow in React. But moving the state “up” can also help with separating presentation from logic.

1 Like
#3

Thanks for the reply. Makes sense. I had it in my head that the SearchBar state would need to be shared, because I assumed that all the API calls would be back on the parent component (where the rest of the data is held in the App.js state), therefore the search term would need to be passed via a callback method (defined on the parent) - i.e. in-line with your comment about separating presentation from logic. I should probably complete the project first before querying things like this!

Admittedly I also haven’t reached lessons on hooks and Redux yet, so I guess it may make more sense once I do.

1 Like
#4

I looked quickly at the code and noticed that once you click the Search button then the search function is called with the term as a parameter. Search function is declared in App.js and passed as a prop. So this will in effect use the search-term at the App-level but only once you press the button. So that function (from app level) does in fact initiate the api-call here.

The local state in search-bar will update on every text-edit change and that can stay local in the component.

#5

Many thanks. I’ve now completed the search functionality (which is working fine for me), and you’re right, that is how it works. The SearchBar component invokes the search method, which is defined in, and passed from, App.js. So the state in SearchBar is purely to hold the latest value that the user enters every time they change the value of the search input field.

Maybe that’s what was confusing me - if that’s all it’s doing, I don’t really understand why you would need state at all in SearchBar. Couldn’t you just pass whatever is the current value of the search field (e.g. this.props.onSearch(document.getElementById(“xxx”).value)) to the method, rather than holding it in state first?

Anyway, no matter, it’s working and I think I follow it all, so many thanks for your help!

#6

There are different ways of doing it but it seems to be pretty much the standard “React” way to keep input and smaller forms in React state and they call it “Controlled components”. You will like the useState hook when you get there since it makes the code significantly shorter and easier. For longer forms it makes more sense to look at alternatives to this solution.

1 Like
#7

Understood. Many thanks again for the help!