 [](https://travis-ci.org/Contiamo/react-connect-context) [ 
With some of our internal applications at Contiamo, the render-prop–style API of React 16.3's new Context API proves to be a bit limiting: particularly the inability to use a consumed context value in component lifecycle hooks. One solution to this is to pass an object _through context_, and then through props.
Instead of repeatedly writing "context containers" that pass context objects to container components through props that _further_ pass state to presentational components through props, this tiny function allows us to give any component easy access to a created context through props, allowing for more idiomatic, predictable code.
If a component has a prop that collides with a context-passed-through prop, the component's prop has precedence. Simple.
1. yarn add react-connect-context
1. At the top of your file, import { connectContext } from "react-connect-context"
1. Wrap your component in the function as so: connectContext(Context.Consumer)(MyComponent)
``jsx
import React from "react"
import { render } from "react-dom"
import { connectContext } from "react-connect-context"
// CHANGE ME TO CHANGE THE CONTEXT FOR THE WHOLE APP!
const COLOR_PASSED_THROUGH_CONTEXT = "red"
interface ContextValue {
color: string;
}
interface ContentProps {
myProp: string;
color: string;
}
class App extends React.Component {
render() {
return (
// Presentational, nested components
const Header: React.SFC = ({ children }) =>
{children}
// Make a context.
const Context = React.createContext
// Pass the consumer to our function.
const ConnectedContent = connectContext
// Render things, wrapping all in the provider.
render(
document.querySelector("#root")
)
`
Sure. Consider using PureComponent or shouldComponentUpdate to let your components know when or when _not_ to update.
Additionally, unlike Redux, React 16.3 allows the creation of _multiple_, composable Contexts, so ideally, you'd be using a Context that is small enough to house _just the information_ that you'd like to reuse in order to properly separate concerns and correctly use the principle of least privilege when passing context around.
For now, _no_. This particular tool is designed to provide a nice cascade of props: if a component has a prop on it, like color from the above example, _that_ prop is used. If it doesn't have a prop, but the prop exists on a Context`, _its_ prop is used.
I would again toot the horn of using multiple small contexts here as above.
The Context value _has_ to be an object since it maps to props by key/value pairs. _Be careful_ if your context is just a string, as in the basic example from React's RFC. This will throw an error that will lead you here. :)
---
Made with ❤️ at Contiamo in Berlin.