Thinking in React: Identifying and Adding States
The course is part of this learning path
This module looks at how to identify state in a React application.
The objectives of this module are to provide you with an understanding of:
- How to identify state
- Where state lives
This learning path is aimed at all who wish to learn how to use the ReactJS framework.
Prerequisites of the Course
We welcome all feedback and suggestions - please contact us at email@example.com to let us know what you think.
- [Instructor] Just to recap, React is primarily for taking data and displaying it. Data flow is unidirectional, flowing 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 is 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 interruption? 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 mutable 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 other state or props in the component? If it can, then it definitely isn't 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 unchanged 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.
About the Author