With what we have done here, you may realize that you have all you could need to handle state, for any application size – and you would be right! You could set up the general state for your whole application in the App component (remember we mentioned that App would have more responsibilities?) and you would be able to do the following:

• Pass it down to components by using props
• Update it in answer to events that the components send

This is a perfectly valid solution, and App.state could have all sorts of data for the whole page. App could handle, for example, calling a web service to get the regions for a given country, storing the results in its state, and passing it to our components so that they can be rendered. In our hardcoded version, RegionsInformationTable had the list of countries (where did it get it from?) and handled the requests for regions (by returning hardcoded data). In reality, as we'll see later in this book, getting this sort of information from a server would be handled differently, and at a higher level: RegionsInformationTable would handle rendering the table and leave data gathering to another part of your solution.

Even if you passed web services handling to App, as your application grows in size, this sort of solution may become unwieldy because of the number of data fields you may have to keep track of. We'll find a better scalable solution for this in Chapter 8, Expanding your Application, by adding a specific package to handle state updates in a more orderly, structured fashion.