Santa React patterns giveaway — 4th week

It’s that time of the year when everyone is sharing love and gif(t)s with their closest ones. Such a pitty that I can only send you a browser cookie and not a real one; instead, I will share four React patterns that I would like you to take home and start using at the beginning of the next year.

New year, new pledges and new React patterns; every week until New Year’s Eve, I will reveal one React pattern that every React developer should know.

If you came across a problem (read challenge) while writing React components and if I faced the same problem as you, then it’s very likely that we’ve solved it in a similar way. Thus, we have a common software problem that we can solve using the same pattern. We can give it a name, describe it and share with other developers so that they can speed up their development process by using an already proven pattern; and this is what we call design patterns.

As this is the last day of the year, we’ll end it with an easy to use pattern, that most of you already know one way or another. This week we’ll explore a pattern called Provider!

Provider

Have you ever been in a situation where you had to pass props to the deeply nested component? I was there, and it looked like I’m going down the rabbit hole! It’s such a common problem, that it even has it’s own name — the prop drilling problem.

Drilling can be fun sometimes

There’s nothing wrong with passing values explicitly to components but when you need to drill down values through so many layers of components then it can become cumbersome. Therefore, we need to find an implicit way of passing values. In the article from the previous week, we used an implicit way of passing values down; it’s React Context API introduced in 16.3. version.

There are three things that we need to know in order to use context api:

1. React.createContext() method,
2. Context.Provider — in charge of providing values,
3. Context.Consumer — consumes values that theprovider provides

Let’s say that Santa is a provider; he brings gifts to all good kids. Instead of visiting each house and drilling through the chimney with his curves, he could just instantly transfer gifts to anyone, no matter how far away they are. On the other side, kids are consumers that can “consume” whatever gift they get from Santa.

In the React world, it would look something like these:

<Santa>
    <Kid/>
    <Kid/>
    <Layer/>
</Santa>

Imagine that theLayer component has more nested components together with theKid component, where we need to pass the data. Using React Context we can avoid drilling down props.

import React, {Component, createContext} from 'react'

const GiftContext = createContext()

class Santa extends Component {
    gifts = ['Chocolate', 'Cookie', 'PS4', '...']
    index = 0

    takeGift = () => this.gifts[this.index++]

    render() {
        return (
            <GiftContext.Provider value={this.takeGift}>
                {this.props.children}
            </GiftContext.Provider>
        )
    }
}

TheSantacomponent is providing thetakeGift method to all GiftContext consumers. In this case, the consumer is theKid component:

class Kid extends Component {
    render() {
        return (
            <GiftContext.Consumer>
                {(takeGift) => (
                    <h1>Yeeeeey! I got {takeGift()}</h1>
                )}
            </GiftContext.Consumer>
        )
    }
}

And that’s all! With this approach, we don’t have to drill down props and worry about nesting our components too deeply as they will implicitly get the props they need.

Provider pattern in the wild

The Provider pattern is a commonly used pattern in the React libraries. For example, Material-UI has the MuiThemeProvider component that takes a theme property and makes it available down the React tree, thanks to React context.

<MuiThemeProvider theme={theme}>
    <Root/>
</MuiThemeProvider>

This component abstracts away the usage of React Context from the developer so he doesn’t need to worry about it’s implementation. Therefore, if the React Context API changes in the future, developers using the MuiThemeProvider component don’t need to update it’s internal implementation, because that’s something what library maintainers will/should do.

Conclusion

This has been a month long journey where we went through some commonly used React patterns. I wish all of you would take and start using them as soon as possible! Also, let’s hope the next year will be Provider which would mean even more cool stuff and knowledge to share!

Danijel is a web developer at COBE. In his spare time, like every other geeky kid, he likes to create pens on Codepen and develop tiny Node apps while listening to RHCP in the background thread. Apart from his JavaScript warrior dreams, he likes to lift weights, eat a lot of chicken and watch crime/thriller movies till the late hours.

Like what you see? Be sure to hit a like and recommend us! And if you want to continue learning, check some other articles:

Santa React patterns giveaway — 3rd week

Santa React patterns giveaway — 2nd week

Santa React patterns giveaway