Just to recap, React is primarily for taking data and displaying it. Data flow is unidirectional flying from the top of a component tree to the bottom. When we build a static version the only data we are concerned about doesn't change over the lifetime of a component, and it's considered as Props. Data that can change should be considered as State, State should be the single source of truth for changing data, any component that relies on this data should receive it as props apart from the highest common component which is where a state should live. 

So if we've covered the first two parts of thinking in React the third part of the process is to identify the minimal but complete representation of UI state, that is, any data that could potentially change while our application is being used. What's an application without interaction? We need our users and other things to be able to trigger changes to the UI display. React makes this easy using a concept called state, but how do we know what state you should be? Best practice suggests thinking of the minimal set of mutable data the application needs, we can compute everything else on demand. 

Following our example of the filterable courses table, we have the following set of beautiful data, the original list of courses, the search text our user enters, the value of the checkbox, and the filtered list of courses. You should recall that props is passed in as an HTML attribute when a component is rendered. To figure out if a piece of data is a candidate for being state, you should ask the following three questions. Is it passed in from a parent via props? If it is, it probably isn't state. Does it remain unchanged over time? If it does, it probably isn't state. Can you compute it based on any of the state or props in the component? If it can, then it definitely isn't the state. 

Again, following our example of the filterable courses table, we can work out that the original list of courses can be passed in as props and does not change over time, therefore it's not state. The search text the user enters, will probably not remain and changed over time therefore, it's likely to be state. The value of checkbox as with the search text probably won't remain unchanged over time, so again, this is likely to be state. The filtered list of courses can be computed by combining the original list of courses, the search text and the checkbox value, therefore, it's not going to be state. 

It's difficult to give you anything other than these guidelines to help, there's always a different way of doing things and that's no different when you're trying to identify state in an application. You just need to try and work out the most logical and efficient way to handle the data in your application.