The key idea behind working with React is that everything – and I mean, everything – is a component. Your whole web application will be a component, itself made of other components, which will themselves have smaller components, and so on. Components generate HTML, which is shown onscreen. The data for the HTML comes from externally assigned props (properties) and internally maintained state. Whenever there is a change in props or state, React takes care of refreshing the HTML so that the view (what the user sees) is always up to date. 

Let's look at an example. Imagine that you want to create a screen that will let the user query data about regions of the world. How could you go about designing it? Check out the following screenshot for details:

Your whole view would be a component, but it's fairly obvious that wouldn't help with coding or testing. A good design principle is that each component should be responsible for a single duty, and if it needs to do more, decompose it into smaller components. In our case, we'd have the following:

• The whole table is a RegionsInformationTable.
• The part at the top can be the CountryFilterBar, with a dropdown for countries
• At the bottom we have a ResultsDataTable, which shows a collection of ExpandableCard components, each with a title, a toggle, and space for more components. We could have designed a specific card for this situation, but having a generic card, whose components may be whatever we want, is more powerful.

A first rule involves events, such as clicks on elements, data being entered, and so on. They should be passed up until a component is able to fully process them: events flow up. For example, when the user clicks on the button, that component shouldn't (and couldn't) fully process it, at the very least because it couldn't access the table. So, the event will be passed up (by means of callbacks) until some component is able to deal with it. You may have options: for example, the CountryFilterBar component could handle calling a service and getting the data, but then it would pass the results up to the RegionsInformationTable, so that it can pass it to the ResultsDataTable component, which will itself produce the necessary ExpandableCard elements. Alternatives would be passing the CountryFilterBar value up to the RegionsInformationTable, which would do the search on its own, or passing it even higher, to some component to do the search and push the data down as props to our big table.

The preceding explanation helps us with a second decision. You should analyze your components hierarchy and decide where data (props or state) should be kept. A key rule is: if two (or more) components share data (or if one component produces data that other component needs). It should belong to a component higher up, which will pass it down as needed: data flows down. In our case, we already applied that rule when we decided that the regions data would be owned by the CountryFilterBar, which was then to be passed to the RegionResults table; each ExpandableCard would only work with the props it receives.

Even if we don't know how to handle web service requests to get the necessary data just yet (or, for example, to initialize the countries dropdown), we can build a static version of our components and see how it works.

It's better to start with these static aspects of web design, and only afterwards deal with the dynamic aspects, such as reacting to events or getting data. Let's get to that code.