Chapter 7: Use Context to Cover an Area
In the previous chapter, we learned how useMemo is designed and how to use useMemo to conditionally reuse the last value. In this chapter, we will talk about how to propagate changes to cover an area update. We will introduce what an area update is and how React context is used to share a value within that area. Then, we will walk through the data structure and source code behind useContext to consume the shared value. And finally, we'll provide two practical examples of applying contexts to the theme and the table. The chapter also includes two bonus topics in the Appendix section: Propagating a context and Context scope and value.
We will cover the following topics in this chapter:
- What is an area update?
- Introducing the React context
- Understanding the useContext design
- Test driving useContext
- useContext examples
- Questions and answers
- Appendix
What is an area update?
On a typical website, once the site is loaded, it starts listening to all user actions. Each action received gets handled on a first-come, first-served basis. Normally, the impact of each action is limited to one small region of the screen, using a UI term, a single component. However, sometimes, a user action can do more than that.
Let's use the computer as an analogy. Say you decide to change the color settings of your system. Once the color is changed, the computer goes through all the open windows and applies that color to them. Therefore, this action can impact multiple applications spread across the screen. This becomes an area update.
Have you wondered how we can make an area update when the impacted components are located very distantly from each other? To be able to answer this question, let's first recall a single update introduced in Chapter 4, Use State to Jumpstart Components.
A fiber tree is scheduled for a single update upon receiving an action. This update is localized around a source fiber where the action is received (the red dot in Figure 7.1). React follows the source and collects all the changes associated with it and then applies them to the DOM (red lines). This is the single update pattern in React.
Figure 7.1 – A single update originating from a user action
Say the source fiber is a Title component:
const Title = () => {
const [count, dispatch] = useState(0)
const onClick = () => {
dispatch(count + 1)
}
return (
<>
<div onClick={onClick}>{count}</div>
...
</>
)
}
The preceding Title component gets updated when the user clicks on count. It should also update other children in the ... section.
Now, consider another component called ThumbUp:
const ThumbUp = () => {
// made up count
return count > 5 ? "Awesome" : ""
}
The intention of the ThumbUp component is to respond to count. When it becomes greater than 5, we want an "Awesome" message to be printed on the screen. The ThumbUp component is located in Figure 7.2:
Figure 7.2 – Two updates responding to a single user action
Currently, the count variable in the ThumbUp component is a made-up one because we don't know how it can be passed from the Title component. All we know is that we want to share this count among both components and the challenge somehow lies in their relationship.
Apparently, these two components are not a child or parent to one another. There's no direct path from one to the other unless we first go upward multiple steps to the Branch component (dark dot in Figure 7.2) and then go down again picking another route. Essentially, Branch is their common ancestor. So how exactly can we send information between two nodes that are not in a direct parent/child relationship?
Let's explore this question by taking two approaches, starting with the props approach.
Props approach
Since the React props only work for the parent/child setup, to apply the props to this problem, we need to promote the relevant state to a common ancestor, the Branch component:
const Branch = () => {
const [count, dispatch] = useState(0)
const onClick = () => {
dispatch(count + 1)
}
return (
<>
<div>
...
<Title count={count} onClick={onClick} />
...
</div>
<div>
...
<ThumbUp count={count} />
...
</div>
</>
)
}
In the preceding code, the count state is relocated from Title to Branch. From there, count and dispatch are then sent to the (distant) children via props. Now, if the state changes, the Branch component updates all its children, including Title and ThumbUp. OK, we managed to share the count state.
Although the props approach works in general, it does require us to modify the props for both the Title and ThumbUp components. Since there can be other components in the path between Branch and each of them, all components along the way need to be modified as well. Considering a typical site build, the need to share a state happens in the later stage of the project cycle. Taking this approach can be very expensive due to the number of components we need to modify.
So, is there a better way of sharing the prop without touching so many components? Looking at Figure 7.2, an intuitive approach could be to dispatch an update to the Title component, and an update to the ThumbUp component at the same time. The combined impact could produce an area update covering both. Let's see if we can make this idea work.
Combined dispatch approach
To have a combined dispatch, we need to allow both dispatches to be accessible from an event handler. This is a bit tricky since a dispatch function provided via useState is normally defined inside one component, either Title or ThumbUp. To get around that, let's say we use a global variable for now:
let dispatch2
const ThumbUp = () => {
const [count, dispatch] = useState(0)
dispatch2 = dispatch
return count > 5 ? "Awesome" : ""
}
In the preceding code, we amended the ThumbUp component and added a count state and a dispatch function. We then used a global variable, dispatch2, to point to this dispatch function so that it can be invoked by other components. Now, with this change, we can ask the Title component to perform both dispatches:
const Title = () => {
const [count, dispatch] = useState(0)
const onClick = () => {
dispatch(v => v + 1)
dispatch2(v => v + 1)
}
return <div onClick={onClick}>{count}</div>
}
From the preceding setup, after the user clicks on count, it performs the dispatch from Title and performs dispatch2 from Greeting. Although the two count states in each component are not pointing to a shared value, both are incremented respectively from these two dispatches. React batches these two dispatches into one update to the screen, and if the user continues clicking the number, you will see an "Awesome" message on the screen when the count state gets bigger than 5.
You might not believe this hack-ish approach would work, but it does. The fact that we call a dispatch function for another component is a bit beyond what React designs useState to do, but it's not incorrect. This approach requires fewer changes to the code structure. There's no prop involved. All changes are made on the local side of Title and ThumbUp. More importantly, it serves as an educational case that an update impacting multiple components can be composed of multiple updates.
OK, what we learned from these two approaches is that we want to avoid passing props all the way down in this non-parent/child case, and we want to share the value as well as trigger a sort of combined update following the value change. Moreover, in practice, if the solution can provide the joint dispatch out of the box and require minor modifications to the existing code structure, that would be even better.
By the end of 2017, the React team found such needs and introduced a new version of context to address its current limitations at that time. What the new context does is that it helps to share a value through multiple levels of components without requiring a prop in each level. It also provides a mechanism for a distant child component to access a value from an ancestor component. Let's take a look at this React context.
Introducing the React context
The context is modeled with a ReactContext data type holding a _currentValue value.
Figure 7.3 – React context data structure
We can create a context with the createContext function. For instance, if we want to share a piece of user info, we can create a UserContext and hold a defaultValue:
const UserContext = createContext(defaultValue)
export default UserContext
The created context can be shared via a JavaScript export statement, and this way, when any other file or component needs it, it can be imported.
The context allows us to provide the value to all consumers underneath via a Provider property:
import UserContext from './UserContext'
const Branch = () => {
return (
<UserContext.Provider value={...}>
...
</UserContext.Provider>
)
}
A context provider, such as UserContext.Provider, accepts a value prop to share. The provider is a special component. Unlike a function component, it has its own update implementation. When it gets updated due to a change in value, it kicks off a search.
The search goes through its children, and its children's children recursively, until everything under gets visited. For all consumers using the context, they are marked to be updated. If you are interested in knowing more about the context provider, check out Appendix A – Propagating a context, at the end of this chapter.
Hence, a provider's job is to share a value. If multiple values of different purposes are required, we can stack them together. Let's say that, on top of UserContext, we have one more ThemeContext context to share:
const Branch = ({ user, theme }) => {
return (
<ThemeContext.Provider value={theme}>
<UserContext.Provider value={user}>
...
</UserContext.Provider>
</ThemeContext.Provider>
)
}
The preceding usage would enable any consumer in the... section to read the value from theme or user, or both.
One interesting aspect regarding the design of the provider is that a provider can be nested under the same provider to override the shared value:
const Branch = ({ theme1, theme2 }) => {
return (
<ThemeContext.Provider value={theme1}>
// A. value = theme1
<ThemeContext.Provider value={theme2}>
// B. value = theme2
</ThemeContext.Provider>
// C. value = theme1
</ThemeContext.Provider>
// D. value = defaultTheme
)
}
In the preceding code, theme1 and theme2 are provided by two providers from the same ThemeContext definition. So, which context value does a consumer see, you might wonder?
There are four locations marked A, B, C, and D in the preceding code. The value a consumer sees depends on where it's consumed. For location A, the value a consumer sees is theme1, for location B, it's theme2, and for location C, it's back to theme1 again.
Essentially, the context provider is designed (in a way) like a JavaScript function. You can get different values in the different function scopes. To figure out the correct value at a particular location, you need to find the first ancestor parent that provides the value. The closest ancestor provider should provide the right context value. This should explain why location C gets theme1 instead of theme2.
Then what is the context value outside of any provider scope, for instance, at location D? Since it does not happen to be an ancestor provider that you can find above the Branch component. This is where defaultValue comes into play:
const ThemeContext = React.createContext(defaultTheme)
When no other provider can be found to provide the value, it takes the defaultValue supplied at the time the context is created. This implies that the default value isn't a must-have, but it can be useful for taking a sneak peek into the format of a context type early on:
const defaultTheme = {
mode: 'light'
}
Internally, React uses a stack to push and pop the context to keep track of context values for all provider scopes. If you are interested in knowing this detail, check out Appendix B – Context scope and value, at the end of this chapter.
OK, now that we know how to provide a context value, let's see how we can consume it in a consumer/child component. React provides a useContext hook to do just that.
Understanding the useContext design
React provides a useContext hook to consume a context:
import UserContext from './UserContext'
const Title = () => {
const user = useContext(UserContext)
return <div>{user.name}</div>
}
The useContext hook function takes one input argument, context, and returns the shared value. context is normally imported from a definition file.
useContext data structure
We are going to explain how useContext is designed with a stripped-down version of the source code. Let's take a look at the data structure that makes it happen:
Figure 7.4 – useContext hook data structure
To consume (or read) a context value, each fiber gets a new dependencies property to keep track of all the context it consumes. This is because a component can use multiple useContext and each usage consumes a different context, such as UserContext and ThemeContext.
The dependencies property is designed as a linked list with its firstContext property to hold the first context with a ContextItem type. Each ContextItem holds a ReactContext (the context introduced earlier) and a next property pointing to the next context. The dependencies list is how the provider finds all consumers while propagating the update.
The useContext hook is designed to read a context value for all updates:
function useContext(context) {
const contextItem = {
context: context,
next: null,
}
if (lastDependency === null) {
lastDependency = contextItem
updatingFiber.dependencies = {
firstContext: contextItem,
}
} else {
lastDependency =
lastDependency.next = contextItem
}
...
}
The main job of useContext in the preceding code block is to return _currentValue from context. It also appends context to the fiber's dependencies list before returning the context value.
lastDependency is an auxiliary variable that keeps track of the last context of the update. If this is the first context, it's then created as firstContext, otherwise it is appended to the next of the list. At the beginning of the update, lastDependency is set to be null. Thus, the list of dependencies for each fiber is recreated in every update, and this reminds us how hooks are created in each update.
useContext workflow
You have gone through a stripped-down version of useContext code. Here is the summary workflow for both provider and useContext:
Figure 7.5 – useContext and ContextProvider workflow
Let's have a quick run-through. A context is provided through a provider. In the event of a value change from the provider, it finds all the consumers and propagates the update. Otherwise, it skips the update.
In an update, when a useContext hook is invoked with a given context, it appends the context to the fiber's dependencies list and returns the context's current value.
Now that we have gone through the overall design, let's take it all out for a test drive.
Test driving useContext
Context is fun to use and has quite a few common applications. Consider a site with a user logo displayed at the top-right corner of the screen:
Figure 7.6 – An application with App, Header, and Logo
The site is created with an App component, containing Header and Main. And in turn, Header contains Logo, and Site contains Greeting. App, Header, and Logo are defined as follows:
function App({ initialUser }) {
const user = initialUser
return (
<div>
<Header user={user} />
<Main user={user} />
</div>
)
}
const Header = ({ user }) => {
return <Logo user={user} />
}
const Logo = ({ user }) => {
return (
<div>
<img url={ user.imageUrl } />
<span>{ user.username }</span>
</div>
)
}
Assuming the user gets authenticated as an initialUser and sent to the App, it gets passed via a prop to Header and Logo. In Logo, it gets consumed by its imageUrl property and username to display a logo. Notice the interface for all components needs to carry user as a prop. Since we want to display a greeting message under Main, the user needs to be passed via a prop as well.
Let's see how a context can help to simplify this setup. Let's say we define a UserContext:
const UserContext = React.createContext()
export default UserContext
In the App, we can provide the initialUser via UserContext.Provider:
import UserContext from './UserContext'
const App = ({ initialUser }) => {
const [user, changeUser] = useState(initialUser)
const value = { user, changeUser }
return (
<UserContext.Provider value={value}>
<div>
<Header />
<Site />
</div>
</UserContext.Provider>
)
}
Notice that Header and Main don't have to carry the user prop anymore.
The App component creates a user state for holding initialUser. The changeUser function can be used to replace the current user if needed. It then assembles a value object from user and changeUser to be shared via UserContext.Provider.
Inside Logo, we can consume the value provided, which includes the user property:
import UserContext from './UserContext'
const Logo = () => {
const { user } = useContext(UserContext)
return (
<div>
<img url={ user.imageUrl } />
<span>{ user.username }</span>
</div>
)
}
In the preceding code, the user object is obtained by reading off the UserContext via an ES6 syntax. For those readers who are interested in knowing about ES6 usages, check out the Embracing JavaScript ES6 section in Chapter 10, Building a Website with React. Once the user is obtained, we can use the imageUrl and username properties of user to quickly wire them to the existing Logo component.
The same applies to the components under Main, such as Greeting, which shows the Hello Fang message depending on the currently logged-in user. We can utilize the context to accomplish that with little effort:
import UserContext from './UserContext'
const Greeting = () => {
const { user } = useContext(UserContext)
return <h1>Hello {user.username}</h1>
}
It's important to note that with a context such as UserContext, our app becomes much more manageable and scalable pertaining to everything about accessing the user object. Because the information becomes context info, as long as the component falls into this context, it can access it.
Now that we know how to read the user object, let's see if we can change it from initialUser, such as allowing the user to log in and out of the app.
Changing the context value
Say we add a Logout button under Logo. When this button is clicked, the current user is logged out, meaning their logo should no longer be available for display:
import UserContext from './UserContext'
const Logo = () => {
const { user, changeUser } = useContext(UserContext)
const { imageUrl, username } = user
const authenticated = username != undefined
const onLogout = () => { changeUser({}) }
const onLogin = () => { // redirect to LoginForm }
return (
<div>
{authenticated ? (
<>
<img url={ imageUrl } />
<span>{ username }</span>
<button onClick={onLogout}>Logout</button>
</>
) : (
<button onClick={onLogin}>Login</button>
)}
</div>
)
}
In the preceding code, the changeUser function is provided via UserContext. It defines an authenticated flag based on whether the username is available. This flag can be used to decide whether the UI should display the Logout or Login button.
If the user is authenticated, the Logout button is displayed. Upon clicking, the onLogout event handler is triggered to changeUser to an empty object, {}. changeUser is a dispatch function we defined earlier, and when it updates the user, it also propagates the update to all consumers, including the Logo component. Thus, when the next update arrives, user holds an empty object with no username.
If the user is not authenticated, the Login button is then displayed. Upon clicking, the onLogin event handler is triggered where we can redirect the user to a LoginForm (the redirection code is omitted here):
const LoginForm = () => {
const { changeUser } = useContext(UserContext)
const onSubmit = (_user) => {
changeUser(_user)
// redirect to home page
}
return ...
}
LoginForm also consumes the UserContext and reads the changeUser property. Upon successful submission of the form, we can use changeUser again to change the empty user into an authenticated user. Similarly, the new update propagates the update to all consumers, including Logo and Greeting. Thus, the user will see their logo and username in the top-right corner after logging in, as well as a greeting message on the main body. See Figure 7.6.
User login and logout are generally important operations for a site because it has a direct impact on site authentication and authorization. Especially when refreshing the page entirely isn't an option, the context is a perfect fit in terms of reading and writing the user object without worrying about the out-of-sync moment among various components.
Now that we have seen how a context update orchestrates the updating of all components in the event of a context change, let's take a look at two more examples using contexts in real applications.
useContext examples
Context is used for sharing site-wise information, but it can be also very effective in sharing things in a narrower area. In this section, we'll see examples of both cases.
Theme context
One nice and common usage involving a context is theming, which allows the user to switch between a light and dark theme based on their preference. See Figure 7.7:
Figure 7.7 – A theme made with light and dark options
To implement this feature, let's start with ThemeContext:
const ThemeContext = React.createContext({
mode: 'light', // or 'dark'
})
We can set the default theme with an object supporting a mode property, which is a string to hold either "light" or "dark".
Design theme context
Any component that requires the theme can read the settings from ThemeContext. Let's build a theme-aware Button component:
const Button = () => {
const theme = useContext(ThemeContext)
return (
<ButtonStyle mode={theme.mode}>
Ok
</ButtonStyle>
}
We can theme the button's style based on the shared mode inside the ButtonStyle component:
const color = props =>
props.mode === 'light' : 'black' ? 'white'
const ButtonStyle = styled.button`
color: ${color};
`
ButtonStyle is a styled component applied on top of the host button component with modified CSS. It receives the mode prop and, based on that, we can define its color with either "white" or "black". If you are interested in using StyledComponent, please check out the Adopting CSS-in-JS approach section of Chapter 10, Building a Website with React.
Based on this approach, we can build lots of other theme-aware components. And imagine a situation where we have a couple of them under App; in the event of the mode changing, they can all be flipped to their corresponding styles in a single update:
const App = ({ theme }) => {
return (
<ThemeContext.Provider value={theme}>
...
</ThemeContext.Provider>
}
Now let's talk about how to design a context. In the preceding theming case, we used mode to flip between themes, but we also can bake the exact style into it:
const ThemeContext = React.createContext({
primaryColor: 'blue',
secondaryColor: 'red'
})
In the preceding context, two individual colors for primary and secondary purposes are defined. This way, we can directly read the color in Button:
const color = props => props.primaryColor
const ButtonStyle = styled.button`
color: ${color};
`
There's no right or wrong in terms of how we should design a context. The decision as to what property you should use is more or less based on how you want to consume these properties and design the components. In our case, the decision is more about whether the component should be based on mode or primaryColor.
Apply theme manually
Using a theme for a group of components works out great with a theme context. However, sometimes there will be a requirement where we want to apply a theme to one particular component without touching the theme of all the other components. This normally applies to a nav header component that gets a different contrast color to the rest of the site.
This problem can be solved by applying a context in a separate scope:
const Header = () => {
return (
<ThemeContext.Provider value={{ mode: 'dark' }}>
<Button />
</ThemeContext.Provider>
)
}
In the preceding Header component, another usage of ThemeContext.Provider is written to provide a different mode theme, while App has already been provided with a mode theme. Let's say the App theme is 'light'; it changes to 'dark' when it enters Header.
When the theme-aware Button component gets updated, it looks for the closest ancestor that defines the provider. Since the ancestor found is Header instead of App, it reads the 'dark' mode.
We are free to override parts of the context value instead of overriding the entire value:
const Header = () => {
const theme = useContext(ThemeContext)
const value = { ...theme, primaryColor: 'blue' }
return (
<ThemeContext.Provider value={value}>
...
</ThemeContext.Provider>
)
}
In the preceding context, Header takes the current theme from the parent scope and overrides the primaryColor property to 'blue'. Thus, all child consumers under Header see a modified theme setting.
Playground – Theme Context
Feel free to play with this online example at https://codepen.io/windmaomao/pen/xxLrwJy.
Now we see that a context is a perfect fit for site-wise subjects such as a theme. The context does not have to always be as big as a site; if we can identify an area, we should be able to apply a context to it. Let's take a look at an example where we apply the context to a targeted area such as a table.
Table context
Another usage of context is to apply the context to a place that can be small but big enough to contain many relevant components inside, such as a table. See Figure 7.8:
Figure 7.8 – A table containing customizable cell displays
A table can be quite complex in a modern UI, where it contains a header, a body, a footer, pagination, and a customizable column setting to drive the look and feel of cells. Moreover, all these elements can be assembled in a mix-and-match way on the fly to suit different business purposes.
Customizing table cells
A table is made up of rows and columns of cells where each cell can be controlled by a cell component such as DefaultCell:
const DefaultCell = ({ value }) => {
return <div>{value}</div>
}
The prop value is used to pass in a primitive value from a property of a row, such as a string or a number. In a typical case, we simply display it as a string format, as in the preceding code.
Given a table row tracking a list of fruits:
const fruits = [
{ title: 'Apple', status: true },
{ title: 'Orange', },
{ title: 'Strawberry' },
{ title: 'Pineapple', status: true },
{ title: 'Watermelon' }
]
The preceding column for title is a perfect example, and it should display a list of fruit names. However, not all cells are plain strings, since we can display a cell as a status indicator, a progress bar, a checkbox, and so on. In our case, we have a column for status indicating whether the fruit tastes nice or just OK, which can be handled by another cell behavior:
const StatusCell = ({ value }) => {
const s = value ? 'Nice' : 'Ok'
return <div>{s}</div>
}
In the preceding custom StatusCell component, the value passed in is a boolean, and it displays either 'Nice' or 'Ok'.
This means we need a generic TableCell where we can pass in some sort of column information to customize the display:
const TableCell = ({ col, row }) => {
const value = row[col.name]
const Component = col.Cell || DefaultCell
return <Component value={value} />
}
In the preceding TableCell component, a col prop is provided to describe how a cell should update. Let's take a look at the information in two columns for both title and status:
const cols = [
{ name: 'title' },
{ name: 'status', Cell: StatusCell }
]
For the second column, the Cell property is specified as a custom StatusCell, whereas the first column omits it, thus taking the DefaultCell. With this col capability, we can design a custom look and feel for all sorts of cells.
Design table context
The example so far displays the cell based on the cell content, row[col.name]. As long as the column name matches the data stored in the row data, we should find the correct cell value. But sometimes, they might not match or, even worse, sometimes we need to display a cell based on multiple columns. For instance, to display a person's full name, we need the person's first name and last name, which are spread out across two columns. Only row can provide enough. But we only have a cell value. Where can we get a row?
We can pass the row into each TableCell as a prop. But say we want to avoid the props approach to keep the cell interface flexible. In this case, we can create a TableContext:
const TableContext = React.createContext({
rows: [],
cols: [],
row: {}
})
export default TableContext
In the preceding TableContext, we add a row property as well as rows and cols so that all consumers can share them. We can then provide it to each row of a table in the TableRow component:
import TableContext from './TableContext'
const TableRow = ({ row }) => {
const table = useContext(TableContext)
const value = { ...table, row }
const cols = table.cols
return (
<TableContext.Provider value={value}>
<TableRowStyle>
{cols.map(col => {
<TableCell
row={row}
col={col}
/>
})}
</TableRowStyle>
</TableContext.Provider>
)
}
The TableRow component is responsible for updating a row of the table. We use TableContext for two purposes here, one to get all the cols stored, and one to override the row property with one provided before providing the context back to each row. Now, when we get to each cell component, we should be able to get the current row. To demo it, we can set up another custom column for 'combo':
const cols = [
{ name: 'title' },
{ name: 'status', Cell: StatusCell },
{ name: 'combo', Cell: ComboCell }
]
The idea of the 'combo' column is to join both 'title' and 'status' in a single cell via a custom ComboCell component:
const ComboCell = () => {
const { row } = useContext(TableContext)
const s = row.status ? 'Nice' : 'Ok'
return <div>{row.title} – {s}</div>
}
In the preceding code, we grab the current row info from TableContext and access both the title and status properties. With this approach, we can literally assemble any information from the current row. Also, notice that there's no props passed into this component. This means, as long as you import TableContext, you can design a custom cell anywhere you want. This decoupling, having no explicit dependency, should make us very comfortable designing a custom cell style on the fly.
We can argue, were we to provide the row directly to the ComboCell, we would achieve the same functionalities without the table context setup. That can be true. The choice of whether you pass the row as a prop or from a context impacts how you design the cells.
In our case, passing row from a context does make the design a bit more flexible. Let's continue our example and see the usage of this TableContext in other places. Let's say this time that a cell needs to know more information, such as the cols settings, or even a piece of action associated with the table, such as deleting a row.
Let's take a look at one example where we delete a row of tables by clicking from a cell. Now, in order to manage the content of the table, we can provide a state [rows, setRows] to the Table component:
const Table = ({ cols, rows, setRows }) => {
const value = { cols, rows, setRows }
return (
<TableContext.Provider value={value}>
<TableStyle>
{rows.map(row => {
<TableRow row={row} />
})}
</TableStyle>
</TableContext.Provider>
)
}
In the preceding code, the Table component is responsible for displaying all the rows of a table. The passed-in rows and cols, as well as a setRows dispatch function, are all sent to the TableContext provider to be consumed. With this, we can define a custom DeleteCell component:
const DeleteCell = () => {
const { row, rows, setRows } = useContext(TableContext)
const onClick = () => {
const newRows = rows.filter(r => r.title !== row.title)
setRows(newRows)
}
return (
<div>
<button onClick={onClick}>Remove</button>
</div>
)
}
In the preceding code, DeleteCell contains a Remove button. When clicked, it first assembles the new table rows, newRows, by filtering out the current row and then uses the setRows dispatch function to replace the table content. Once rows is updated, it should trigger a provider update and thereby propagate a change to all table components.
Without a context to provide setRows, it would have to be passed through lots of layers to reach DeleteCell. Even in this brief example, the number of layers is not straightforward. Moreover, in this case, we don't exactly know the name of the component beforehand. It could be DeleteCell or DefaultCell, or any cell component that hasn't been designed yet. Therefore, the context usage here is really helpful in delivering things to an area underneath without knowing the exact location.
Playground – Table Context
Feel free to play with this online example at https://codepen.io/windmaomao/pen/VwzWeMa.
Let's conclude this table example by means of Table component usage under the App component:
const cols = [
{ name: 'combo', Cell: ComboCell },
{ name: 'action', Cell: DeleteCell }
]
const App = () => {
const [rows, setRows] = useState(fruits)
return <Table
rows={rows}
cols={cols}
setRows={setRows}
/>
}
Summary
We learned a really cool concept in this chapter, that is, a context. First, we got to know what is a context under React. We then dug deeper into the context design as well as how to consume it with a useContext hook. We then went through a context test drive by managing a user object for a site and further learned two more applications of applying contexts to the Theme and the Table.
In the next chapter, we will get into our next hook in the React family and see how a ref can be used to hide private matters away from the engine.
Questions and answers
The following are some questions and answers to refresh your knowledge:
- What is a React context?
A React context is an identity that can be used to share a value with consumers. It's designed so that a value can be provided to a localized scope, hence all components within that scope can read from this shared value.
- What is the useContext hook?
The useContext hook is used in a consumer component so that it can read a context given by providers. A component can consume as many contexts as it can. When the provider gets updated, all the consumer components for that particular context get updated at the same time.
- What's the common usage of useContext?
The useContext hook is a hook in the React hook family when it comes to an update involving an area of components. We often see this context usage in User, Theme, and Table, which requires the consumption of a value under an ancestor component without passing it explicitly through layers of components. The useContext hook also makes it possible to deliver a value to an area without knowing exactly where the destination is.
Appendix
Appendix A – Propagating a context
React comes with different kinds of fibers. While a function component is one of them, the context provider is another one. It gets its own update logic with each update:
function updateContextProvider(fiber) {
var providerType = fiber.type
var context = providerType._context
var newProps = fiber.pendingProps
var oldProps = fiber.memoizedProps
var newValue = newProps.value
if (oldProps !== null) { ... }
var children = newProps.children
reconcileChildren(fiber, children)
return fiber.child
}
In the preceding code, the updateContextProvider function takes in fiber, and checks whether it has been mounted or not via oldProps !== null. If it's a first-time mount, then it does things similar to a function component, reconciling the children into fibers and then returning the first child to work on next.
If it's not the first time, such as during an update, it then compares the value prop between oldValue and newValue:
if (oldProps !== null) {
var oldValue = oldProps.value
if (oldValue === newValue) {
if (oldProps.children === newProps.children) {
return bailoutOnAlreadyFinishedWork(fiber)
}
} else {
propagateContextChange(fiber, context)
}
}
If it turns out that there's no change in the value provided from the strict equal comparison, ===, and if there's no change in the children, it then bails out the fiber and skips the reconciliation. Otherwise, if there's a change in the value provided, it propagates the context change to all its consumer fibers via the propagateContextChange function:
function propagateContextChange(work, context) {
var fiber = work.child;
while (fiber !== null) {
var nextFiber = void 0
var list = fiber.dependencies;
if (list !== null) {
nextFiber = fiber.child;
var dependency = list.firstContext;
while (dependency !== null) {
if (dependency.context === context) {
scheduleWorkOnParentPath(fiber.return)
break
}
dependency = dependency.next;
}
} else {
nextFiber = fiber.child;
}
...
fiber = nextFiber;
}
}
The propagation goes for a deep search under the fiber fiber and checks to see whether it contains the same context as per the firstContext. If it finds a match, it invokes a scheduleWorkOnParentPath function to schedule an update along the path from the root to the parent. This function is quite similar to scheduleUpdateOnFiber, which we see in the useState hook. But here, instead of doing it once, this function is applied to all consumers found.
In short, you can see that a provider is a special component that schedules an update for all consumers reading from the same context.
Appendix B – Context scope and value
A context value changes under different scopes of a context. But what does this statement mean?
Const provider1 = (value) => {
const provider2 = (value) => {
const provider3 = (value) => {
console.log(value)
}
provider3(3)
}
provider2(2)
}
provider1(1)
In the preceding convoluted example, can you guess what the output is if we invoke provider1(1)? Please take a minute to think. The answer is 3.
Because each function has a scope, within the scope of the function, all local variables from the input argument take precedence. Though the outer value is 1, the inner value becomes 3 due to the change of scope.
The context provider is designed in a similar fashion; it uses a stack to push the old value in before entering one scope, and then pop the old value out after leaving the same scope. This way, an outer scope is always kept in memory when we work in an inner scope.
Let's take a look at this process closely. Say cursor holds the value in one outer scope, and it wants to enter the inner scope with a new value:
function push(cursor, value) {
index++
valuesStack[index] = cursor.current
cursor.current = value
}
In the preceding code, cursor is a global variable, which holds the current value under the current property. The push operation puts the old value in the stack and then replaces the current value of cursor with the new value.
Therefore, once we enter the inner scope, the current of cursor is updated to the latest, so how do we get back the old value once we finish this inner scope? Yes, we perform a pop operation:
function pop(cursor) {
if (index < 0) return
cursor.current = valueStack[index]
valueStack[index] = null
index--
}
In the preceding code, we pop the previous stacked value back to the cursor. So now, when we get out of the inner scope, the value gets back to the old value.
This mechanism is exactly what's applied to our context provider:
function updateContextProvider(fiber) {
...
pushProvider(fiber, newValue)
if (oldProps !== null) { ... }
...
}
When it gets to the update of a provider, it pushes the old value and replaces it with a new value with a pushProvider function:
function pushProvider(fiber, nextValue) {
var context = fiber.type._context
push(valueCursor, context._currentValue)
context._currentValue = nextValue;
}
The last line of pushProvider sets the _currentValue of the context with the nextValue from the value prop. This is how the consumer in the inner scope gets the inner value. But before that, it pushes an old value of _currentValue in the stack and stores it in a global variable, valueCursor.
Before we move out of the provider's scope, popProvider is invoked:
function popProvider(fiber) {
var currentValue = valueCursor.current
pop(valueCursor)
var context = fiber.type._context
context._currentValue = currentValue
}
The last line of popProvider sets the currentValue of the context back to the saved value from valueCursor. But before that, it pops the old value from the stack.
So, at all times, there's a valueCursor to hold the outer scope value, while context._currentValue holds the current/inner scope value. This means that the context value stored in _currentValue is not a fixed value throughout the update. Hopefully, you can now see that a context has a "global" sense and varies based on the scope.
