Let's talk about my understanding and application of React Context

Preface
First look at React Context
How to use Context
Several places where you can directly obtain Context
My understanding of Context

Treat Context as component scope

Focus on the controllability and impact of Context

No need to use Context first

Use Context as a medium for sharing data

Developing components using Context

Slot Distribution Components

Component implementation ideas

Implement slot distribution components according to the idea

Can make <AppLayout /> more versatile

Try the new Context API

Summarize

References

Preface

Context is translated as context. In the field of programming, this is a concept that is often encountered, and it also exists in React.

In the official documentation of React, Context is classified as Advanced and belongs to React's advanced API, but the official does not recommend using Context in the stable version of the App.

The vast majority of applications do not need to use content.
If you want your application to be stable, don't use context. It is an experimental API and it is likely to break in future releases of React.

However, this does not mean that we do not need to pay attention to Context. In fact, many excellent React components use Context to complete their functions. For example, react-redux's <Provider /> provides a global store through Context. The drag component react-dnd distributes DOM Drag and Drop events in components through Context. The routing component react-router manages routing status through Context, and so on. In React component development, if you use Context well, your components can become powerful and flexible.

Today I want to talk to you about what I learned about Context during development and how I use it to develop components.

Note: All apps mentioned in this article refer to web apps.

First look at React Context

Official definition of Context

The React documentation website does not give a definition of "what is Context", but rather describes the scenarios in which Context is used and how to use Context.

The official website describes the scenario of using Context as follows:

In Some Cases, you want to pass data through the component tree without having to pass the props down manuallys at every level. you can do this directly in React with the powerful "context" API.

Simply put, when you don't want to pass data by passing props or state layer by layer in the component tree, you can use Context to implement cross-level component data transfer.

Use props or state to pass data, and the data flows from top to bottom.

Using Context, data can be passed across components.

How to use Context

For Context to work, two components are needed: a Context producer (Provider), which is usually a parent node, and a Context consumer (Consumer), which is usually one or more child nodes. Therefore, the use of Context is based on the producer-consumer model.

For the parent component, that is, the Context producer, it is necessary to declare the properties of the Context object provided to the child component through a static property childContextTypes, and implement an instance getChildContext method to return a plain object representing the Context.

import React from 'react'
import PropTypes from 'prop-types'

class MiddleComponent extends React.Component {
 render () {
 return <ChildComponent />
 }
}

class ParentComponent extends React.Component {
 //Declare Context object properties static childContextTypes = {
 propA: PropTypes.string,
 methodA: PropTypes.func
 }
 
 // Return the Context object. The method name is the agreed getChildContext () {
 return {
  propA: 'propA',
  methodA: () => 'methodA'
 }
 }
 
 render () {
 return <MiddleComponent />
 }
}

For Context consumers, access the Context provided by the parent component in the following way.

import React from 'react'
import PropTypes from 'prop-types'

class ChildComponent extends React.Component {
 //Declare the Context properties you need to use static contextTypes = {
 propA: PropTypes.string
 }
 
 render () {
 const {
  propA,
  methodA
 } = this.context
 
 console.log(`context.propA = ${propA}`) // context.propA = propA
 console.log(`context.methodA = ${methodA}`) // context.methodA = undefined
 
 return ...
 }
}

The child component needs to be declared through a static property contextTypes before it can access the properties of the parent component Context object. Otherwise, even if the property name is not written incorrectly, the object obtained is undefined.

For stateless subcomponents, you can access the parent component's Context in the following ways:

import React from 'react'
import PropTypes from 'prop-types'

const ChildComponent = (props, context) => {
 const {
 propA
 } = context
 
 console.log(`context.propA = ${propA}`) // context.propA = propA
 
 return ...
}
 
ChildComponent.contextProps = {
 propA: PropTypes.string 
}

In the next release, React adjusted the Context API to make the use of the producer-consumer model more clear.

import React from 'react';
import ReactDOM from 'react-dom';

const ThemeContext = React.createContext({
 background: 'red',
 color: 'white'
});

Create a Context object through the static method React.createContext(). This Context object contains two components, <Provider /> and <Consumer />.

class App extends React.Component {
 render () {
 return (
  <ThemeContext.Provider value={{background: 'green', color: 'white'}}>
  <Header />
  </ThemeContext.Provider>
 );
 }
}

The value of <Provider /> is equivalent to the current getChildContext().

class Header extends React.Component {
 render () {
 return (
  <Title>Hello React Context API</Title>
 );
 }
}
 
class Title extends React.Component {
 render () {
 return (
  <ThemeContext.Consumer>
  {context => (
   <h1 style={{background: context.background, color: context.color}}>
   {this.props.children}
   </h1>
  )}
  </ThemeContext.Consumer>
 );
 }
}

The children of <Consumer /> must be a function, and the Context provided by <Provider /> is obtained through the function parameters.

It can be seen that Context's new API is closer to the style of React.

Several places where you can directly obtain Context

In fact, in addition to the instance's context property (this.context), React components have many other places where they can directly access the Context provided by the parent component. For example, the construction method:

constructor(props, context)

For example, the life cycle:

componentWillReceiveProps(nextProps, nextContext)
shouldComponentUpdate(nextProps, nextState, nextContext)
componentWillUpdate(nextProps, nextState, nextContext)

For function-oriented stateless components, the component's Context can be directly accessed through the function's parameters.

const StatelessComponent = (props, context) => (
 ......
)

The above is the basics of Context. For more detailed guidance, please refer to here

My understanding of Context

OK, after talking about the basics, let me now talk about my understanding of React's Context.

Treat Context as component scope

Developers who use React know that a React App is essentially a React component tree. Each React component is equivalent to a node on this tree. Except for the root node of the App, each other node has a parent component chain.

For example, in the figure above, the parent component chain of <Child /> is <SubNode /> -- <Node /> -- <App />, the parent component chain of <SubNode /> is <Node /> -- <App />, and the parent component chain of <Node /> has only one component node, which is <App />.

These tree-connected component nodes actually form a Context tree. The Context of each node is an object composed of the Context objects provided by all component nodes on the parent component chain through getChildContext().

Developers who are familiar with the concept of JS scope chain should all know that during the execution of a JS code block, a corresponding scope chain will be created. This scope chain records the active objects that can be accessed during the execution of the JS code block at runtime, including variables and functions. The JS program accesses variables and functions inside or outside the code block through the scope chain.

If we use the JS scope chain as an analogy, the Context object provided by the React component is actually like a scope provided to child components for access, and the properties of the Context object can be seen as active objects in the scope. Since the Context of a component is composed of the Context objects returned by all components on its parent node chain through getChildContext(), the component can access the properties of the Context provided by all node components on its parent component chain through Context.

Therefore, I borrowed the idea of JS scope chain and used Context as the scope of the component.

Focus on the controllability and impact of Context

However, Context as a component scope is different from the common concept of scope (as far as the programming languages I have come into contact with are concerned). We need to focus on the controllability and impact of Context.

In our daily development, the use of scope or context is very common, natural, and even unconscious. However, using Context in React is not that easy. The parent component needs to "declare" the Context provided by it through childContextTypes, and the child component needs to "apply" for the Context property of the parent component through contextTypes. Therefore, I think React's Context is a " permissioned" component scope.

What are the benefits of this “authorized” approach? As far as I understand it, the first thing is to maintain the consistency of the framework API, and use a declarative coding style, just like propTypes. In addition, the controllability and scope of influence of the Context provided by the component can be ensured to a certain extent.

React App's components are tree-like structures, extending layer by layer, and parent-child components are one-to-many linear dependencies. Random use of Context will actually destroy this dependency relationship, resulting in some unnecessary additional dependencies between components, reducing the reusability of components, and may affect the maintainability of the App.

From the above figure, we can see that the original linearly dependent component tree, because the child component uses the parent component's Context, causes the <Child /> component to have dependencies on both <Node /> and <App />. Once separated from these two components, the availability of <Child /> cannot be guaranteed, reducing the reusability of <Child />.

In my opinion, exposing data or API through Context is not an elegant practice, even though react-redux does it this way. Therefore, a mechanism, or constraint, is needed to reduce unnecessary impacts.

By constraining the two static properties of childContextTypes and contextTypes, it can be guaranteed to a certain extent that only the component itself, or other child components related to the component, can access the properties of the Context at will, whether it is data or function. Because only the component itself or related child components can clearly know which Context properties it can access, and for other components that are not related to the component, whether internal or external, it is unclear which Context properties are "declared" by the childContextTypes of each parent component in the parent component chain, so it is impossible to "apply" for related properties through contextTypes. So I understand that giving the component's scope Context "authority" can ensure the controllability and scope of influence of the Context to a certain extent.

In the process of developing components, we should always pay attention to this and not use Context casually.

No need to use Context first

As a high-level API of React, React does not recommend that we give priority to using Context. My understanding is:

Context is still in the experimental stage and may undergo major changes in later releases. In fact, this has already happened. Therefore, in order to avoid major impact and trouble on future upgrades, it is not recommended to use Context in App.
Although it is not recommended to use Context in App, for components, since the scope of influence is smaller than App, if high cohesion can be achieved without destroying the dependencies of the component tree, then you can still consider using Context.
For data communication or state management between components, give priority to using props or state, and then consider using other third-party mature libraries. When the above methods are not the best choice, then consider using Context.
Context updates need to be triggered by setState(), but this is not reliable. Context supports cross-component access. However, if the intermediate subcomponent does not respond to updates through some methods, such as shouldComponentUpdate() returns false, then there is no guarantee that the update of Context will reach the subcomponent using Context. Therefore, the reliability of Context requires attention. However, the update problem has been solved in the new version of the API.

In short, as long as you can ensure that Context is controllable, there is no problem in using Context. If it can be applied reasonably, Context can actually bring a very powerful experience to React component development.

Use Context as a medium for sharing data

The official Context can be used for cross-component data communication. I understand it as a bridge, a medium for sharing data. Data sharing can be divided into two categories: App level and component level.

App-level data sharing

The Context object provided by the App root node component can be regarded as the global scope of the App level, so we use the Context object provided by the App root node component to create some App-level global data. For ready-made examples, please refer to react-redux. The following is the core implementation of the <Provider /> component source code:

export function createProvider(storeKey = 'store', subKey) {
 const subscriptionKey = subKey || `${storeKey}Subscription`

 class Provider extends Component {
  getChildContext() {
   return { [storeKey]: this[storeKey], [subscriptionKey]: null }
  }

  constructor(props, context) {
   super(props, context)
   this[storeKey] = props.store;
  }

  render() {
   return Children.only(this.props.children)
  }
 }

 // ......

 Provider.propTypes = {
  store: storeShape.isRequired,
  children: PropTypes.element.isRequired,
 }
 Provider.childContextTypes = {
  [storeKey]: storeShape.isRequired,
  [subscriptionKey]: subscriptionShape,
 }

 return Provider
}

export default createProvider()

When the root component of the App is wrapped with the <Provider /> component, it essentially provides a global property store for the App, which is equivalent to sharing the store properties across the entire App. Of course, the <Provider /> component can also be wrapped in other components to share the store globally at the component level.

Component-level data sharing

If the function of a component cannot be completed by the component itself and needs to rely on additional sub-components, you can use Context to build a component composed of multiple sub-components. For example, react-router.

react-router's <Router /> cannot independently complete routing operations and management, because navigation links and redirected content are usually separated, so it is also necessary to rely on subcomponents such as <Link /> and <Route /> to complete routing related work together. In order to make related sub-components work together, the implementation of react-router is to use Context to share a router among related components such as <Router />, <Link /> and <Route />, thereby completing the unified operation and management of routing.

The following is a partial source code of the relevant components <Router />, <Link /> and <Route /> to better understand the above.

// Router.js

/**
 * The public API for putting history on context.
 */
class Router extends React.Component {
 static propTypes = {
 history: PropTypes.object.isRequired,
 children: PropTypes.node
 };

 static contextTypes = {
 router: PropTypes.object
 };

 static childContextTypes = {
 router: PropTypes.object.isRequired
 };

 getChildContext() {
 return {
  router: {
  ...this.context.router,
  history: this.props.history,
  route: {
   location: this.props.history.location,
   match: this.state.match
  }
  }
 };
 }
 
 // ......
 
 componentWillMount() {
 const { children, history } = this.props;
 
 // ......
 
 this.unlisten = history.listen(() => {
  this.setState({
  match: this.computeMatch(history.location.pathname)
  });
 });
 }

 // ......
}

Although there are other logics in the source code, the core of <Router /> is to provide a Context with a router attribute for the child component, monitor the history at the same time, and trigger the component to re-render through setState() once the history changes.

// Link.js

/**
 * The public API for rendering a history-aware <a>.
 */
class Link extends React.Component {
 
 // ......
 
 static contextTypes = {
 router: PropTypes.shape({
  history: PropTypes.shape({
  push: PropTypes.func.isRequired,
  replace: PropTypes.func.isRequired,
  createHref: PropTypes.func.isRequired
  }).isRequired
 }).isRequired
 };

 handleClick = event => {
 if (this.props.onClick) this.props.onClick(event);

 if (
  !event.defaultPrevented &&
  event.button === 0 &&
  !this.props.target &&
  !isModifiedEvent(event)
 ) {
  event.preventDefault();
  // Use the router instance provided by the <Router /> component const { history } = this.context.router;
  const { replace, to } = this.props;

  if (replace) {
  history.replace(to);
  } else {
  history.push(to);
  }
 }
 };
 
 render() {
 const { replace, to, innerRef, ...props } = this.props;

 // ...

 const { history } = this.context.router;
 const location =
  typeof to === "string"
  ? createLocation(to, null, null, history.location)
  : to;

 const href = history.createHref(location);
 return (
  <a {...props} onClick={this.handleClick} href={href} ref={innerRef} />
 );
 }
}

The core of <Link /> is to render the <a> tag, intercept the click event of the <a> tag, and then perform routing operations on the history through the router shared by <Router />, and then notify <Router /> to re-render.

// Route.js

/**
 * The public API for matching a single path and rendering.
 */
class Route extends React.Component {
 
 // ......
 
 state = {
 match: this.computeMatch(this.props, this.context.router)
 };

 // Calculate the matching path. If it matches, it will return a matching object, otherwise it will return null
 computeMatch(
 { computedMatch, location, path, strict, exact, sensitive },
 router
 ) {
 if (computedMatch) return computedMatch;
 
 // ......

 const { route } = router;
 const pathname = (location || route.location).pathname;
 
 return matchPath(pathname, { path, strict, exact, sensitive }, route.match);
 }
 
 // ......

 render() {
 const { match } = this.state;
 const { children, component, render } = this.props;
 const { history, route, staticContext } = this.context.router;
 const location = this.props.location || route.location;
 const props = { match, location, history, staticContext };

 if (component) return match ? React.createElement(component, props) : null;

 if (render) return match ? render(props) : null;

 if (typeof children === "function") return children(props);

 if (children && !isEmptyChildren(children))
  return React.Children.only(children);

 return null;
 }
}

<Route /> has some source code similar to <Router />, which can realize nested routes, but its core is to determine whether the path of the current route is matched through the router shared by Context, and then render the component.

Through the above analysis, we can see that the entire react-router is actually built around the Context of <Router />.

Developing components using Context

Previously, a simple component, the slot distribution component, was developed through Context. This chapter will use the development experience of this slot distribution component to talk about how to use Context to develop components.

Slot Distribution Components

First, let’s talk about what slot distribution components are. This concept was first introduced in Vuejs. Slot distribution is a technology that inserts the content of a parent component into the template of a child component through the combination of components. It is called Slot in Vuejs.

In order to make everyone understand this concept more intuitively, I moved a demo about slot distribution from Vuejs.

For the component <my-component /> with the provided slot, the template is as follows:

<div>
 <h2>I am the title of the subcomponent</h2>
 <slot>
 Only displayed if there is no content to distribute</slot>
</div>

For the parent component, the template is as follows:

<div>
 <h1>I am the title of the parent component</h1>
 <my-component>
 <p>This is some initial content</p>
 <p>This is more initial content</p>
 </my-component>
</div>

The final rendered result:

<div>
 <h1>I am the title of the parent component</h1>
 <div>
 <h2>I am the title of the subcomponent</h2>
 <p>This is some initial content</p>
 <p>This is more initial content</p>
 </div>
</div>

You can see that the <slot /> node of the component <my-component /> is eventually replaced by the content under the <my-component /> node in the parent component.

Vuejs also supports named slots.

For example, a layout component <app-layout />:

<div class="container">
 <header>
 <slot name="header"></slot>
 </header>
 <main>
 <slot></slot>
 </main>
 <footer>
 <slot name="footer"></slot>
 </footer>
</div>

And in the parent component template:

<app-layout>
 <h1 slot="header">This may be a page title</h1>
 <p>A paragraph of main content. </p>
 <p>Another paragraph. </p>
 <p slot="footer">Here is some contact information</p>
</app-layout>

The final rendered result:

<div class="container">
 <header>
 <h1>This may be a page title</h1>
 </header>
 <main>
 <p>A paragraph of main content. </p>
 <p>Another paragraph. </p>
 </main>
 <footer>
 <p>Here is some contact information</p>
 </footer>
</div>

The benefit of slot distribution is that it allows components to be abstracted into templates. The component itself only cares about the template structure, and leaves the specific content to the parent component to handle. At the same time, it does not break the grammatical expression of HTML describing the DOM structure. I think this is a very meaningful technology, but unfortunately, React's support for this technology is not very friendly. So I referred to the slot distribution component of Vuejs and developed a set of slot distribution components based on React, which can make React components also have template capabilities.

For the <AppLayout /> component, I would like to write it like this:

class AppLayout extends React.Component {
 static displayName = 'AppLayout'
 
 render () {
 return (
  <div class="container">
  <header>
   <Slot name="header"></Slot>
  </header>
  <main>
   <Slot></Slot>
  </main>
  <footer>
   <Slot name="footer"></Slot>
  </footer>
  </div>
 )
 }
}

When used in the outer layer, it can be written like this:

<AppLayout>
 <AddOn slot="header">
 <h1>This may be a page title</h1>
 </AddOn>
 <AddOn>
 <p>A paragraph of main content. </p>
 <p>Another paragraph. </p>
 </AddOn>
 <AddOn slot="footer">
 <p>Here is some contact information</p>
 </AddOn>
</AppLayout>

Component implementation ideas

Based on what I have thought about before, let’s first sort out the implementation ideas.

It is not difficult to see that the slot distribution component needs to rely on two sub-components - the slot component <Slot /> and the distribution component <AddOn />. The slot component is responsible for piling and providing slots for distributing content. The distribution component is responsible for collecting the distribution content and providing it to the slot component to render the distribution content. It is equivalent to the consumer of the slot.

Obviously, there is a problem here. The <Slot /> component is independent of the <AddOn /> component. How to fill the content of <AddOn /> into <Slot />? It is not difficult to solve this problem. If two independent modules need to be connected, just build a bridge between them. So how do we build this bridge? Let's look back at the code we imagined earlier.

For the <AppLayout /> component, you want to write it like this:

class AppLayout extends React.Component {
 static displayName = 'AppLayout'
 
 render () {
 return (
  <div class="container">
  <header>
   <Slot name="header"></Slot>
  </header>
  <main>
   <Slot></Slot>
  </main>
  <footer>
   <Slot name="footer"></Slot>
  </footer>
  </div>
 )
 }
}

When used in the outer layer, it is written like this:

<AppLayout>
 <AddOn slot="header">
 <h1>This may be a page title</h1>
 </AddOn>
 <AddOn>
 <p>A paragraph of main content. </p>
 <p>Another paragraph. </p>
 </AddOn>
 <AddOn slot="footer">
 <p>Here is some contact information</p>
 </AddOn>
</AppLayout>

Whether it is <Slot /> or <AddOn />, they are actually within the scope of <AppLayout />. <Slot /> is the component node returned by the render() method of the <AppLayout /> component, and <AddOn /> is the children node of <AppLayout />. Therefore, <AppLayout /> can be regarded as a bridge between <Slot /> and <AddOn />. So, how does <AppLayout /> establish a connection between <Slot /> and <AddOn />? Here we use the protagonist of this article - Context. The next question is, how to use Context to establish a connection between <Slot /> and <AddOn />?

The bridge <AppLayout /> was mentioned earlier. In the outer component, <AppLayout /> is responsible for collecting the content to fill the slot through <AddOn />. <AppLayout /> defines an interface for obtaining filling content with the help of Context. When rendering, because <Slot /> is the node rendered by <AppLayout />, <Slot /> can obtain the interface for obtaining the filling content defined by <AppLayout /> through Context, and then obtain the filling content through this interface for rendering.

Implement slot distribution components according to the idea

Since <AddOn /> is a child node of <AppLayout />, and <AddOn /> is a specific component, we can identify it by name or displayName. Therefore, before rendering, that is, before render() returns, <AppLayout /> traverses the children and caches each child of <AddOn /> using the value of slot as the key. If <AddOn /> does not set a slot, it is considered to be filling the unnamed <Slot />. We can give these unnamed slots a key, such as $$default.

For <AppLayout />, the code is as follows:

class AppLayout extends React.Component {
 
 static childContextTypes = {
 requestAddOnRenderer: PropTypes.func
 }
 
 // Used to cache the content of each <AddOn /> addOnRenderers = {}
 
 // Provide interface getChildContext () for child nodes through Context {
 const requestAddOnRenderer = (name) => {
  if (!this.addOnRenderers[name]) {
  return undefined
  }
  return () => (
  this.addOnRenderers[name]
  )
 }
 return {
  requestAddOnRenderer
 }
 }

 render () {
 const {
  children,
  ...restProps
 } = this.props

 if (children) {
  // Cache the contents of <AddOn /> in kv mode const arr = React.Children.toArray(children)
  const nameChecked = []
  this.addOnRenderers = {}
  arr.forEach(item => {
  const itemType = item.type
  if (item.type.displayName === 'AddOn') {
   const slotName = item.props.slot || '$$default'
   // Ensure content uniqueness if (nameChecked.findIndex(item => item === stubName) !== -1) {
   throw new Error(`Slot(${slotName}) has been occupied`)
   }
   this.addOnRenderers[stubName] = item.props.children
   nameChecked.push(stubName)
  }
  })
 }

 return (
  <div class="container">
  <header>
   <Slot name="header"></Slot>
  </header>
  <main>
   <Slot></Slot>
  </main>
  <footer>
   <Slot name="footer"></Slot>
  </footer>
  </div>
 )
 }
}

<AppLayout /> defines a Context interface requestAddOnRenderer(). The requestAddOnRenderer() interface returns a function based on name. The returned function accesses the properties of addOnRenderers based on name. addOnRenderers is the content cache object of <AddOn />.

The implementation of <Slot /> is very simple, the code is as follows:

// props, context
const Slot = ({ name, children }, { requestAddOnRenderer }) => {
 const addOnRenderer = requestAddOnRenderer(name)
 return (addOnRenderer && addOnRenderer()) ||
 children ||
 null
}

Slot.displayName = 'Slot'
Slot.contextTypes = { requestAddOnRenderer: PropTypes.func }
Slot.propTypes = { name: PropTypes.string }
Slot.defaultProps = { name: '$$default' }

It can be seen that <Slot /> obtains the requestAddOnRenderer() interface provided by <AppLayout /> through context, and the main object of final rendering is the content of <AddOn /> cached in <AppLayout />. If the content of the specified <AddOn /> is not obtained, the children of <Slot /> itself are rendered.

<AddOn /> is even simpler:

const AddOn = () => null

AddOn.propTypes = { slot: PropTypes.string }
AddOn.defaultTypes = { slot: '$$default' }
AddOn.displayName = 'AddOn'

<AddOn /> does nothing but returns null. Its function is to let <AppLayout /> cache the content distributed to the slot.

Can make <AppLayout /> more versatile

Through the above code, <AppLayout /> is basically transformed into a component with slot distribution capabilities, but it is obvious that <AppLayout /> is not universal. We can promote it to an independent and universal component.

I named this component SlotProvider

function getDisplayName (component) {
 return component.displayName || component.name || 'component'
}

const slotProviderHoC = (WrappedComponent) => {
 return class extends React.Component {
 static displayName = `SlotProvider(${getDisplayName(WrappedComponent)})`

 static childContextTypes = {
  requestAddOnRenderer: PropTypes.func
 }
 
 // Used to cache the content of each <AddOn /> addOnRenderers = {}
 
 // Provide interface getChildContext () for child nodes through Context {
  const requestAddOnRenderer = (name) => {
  if (!this.addOnRenderers[name]) {
   return undefined
  }
  return () => (
   this.addOnRenderers[name]
  )
  }
  return {
  requestAddOnRenderer
  }
 }

 render () {
  const {
  children,
  ...restProps
  } = this.props

  if (children) {
  // Cache the contents of <AddOn /> in kv mode const arr = React.Children.toArray(children)
  const nameChecked = []
  this.addOnRenderers = {}
  arr.forEach(item => {
   const itemType = item.type
   if (item.type.displayName === 'AddOn') {
   const slotName = item.props.slot || '$$default'
   // Ensure content uniqueness if (nameChecked.findIndex(item => item === stubName) !== -1) {
    throw new Error(`Slot(${slotName}) has been occupied`)
   }
   this.addOnRenderers[stubName] = item.props.children
   nameChecked.push(stubName)
   }
  })
  }
  
  return (<WrappedComponent {...restProps} />)
 }
 }
}

export const SlotProvider = slotProviderHoC

Use React's high-order components to transform the original <AppLayout /> into an independent and general component. For the original <AppLayout />, you can use this SlotProvider high-order component to convert it into a component with slot distribution capabilities.

import { SlotProvider } from './SlotProvider.js'

class AppLayout extends React.Component {
 static displayName = 'AppLayout'
 
 render () {
 return (
  <div class="container">
  <header>
   <Slot name="header"></Slot>
  </header>
  <main>
   <Slot></Slot>
  </main>
  <footer>
   <Slot name="footer"></Slot>
  </footer>
  </div>
 )
 }
}

export default SlotProvider(AppLayout)

Through the above experience, we can see that when designing and developing a component,

A component may require a root component and multiple subcomponents to work together to complete the component function. For example, the slot distribution component actually requires SlotProvider to be used together with <Slot /> and <AddOn />. SlotProvider is the root component, while <Slot /> and <AddOn /> are both subcomponents.
The position of a subcomponent relative to the root component or between subcomponents is undefined. For SlotProvider, the position of <Slot /> is uncertain. It will be located anywhere in the template of the component wrapped by the SlotProvider high-order component. For <Slot /> and <AddOn />, their direct positions are also uncertain. One is inside the component wrapped by SlotProvider, and the other is the children of SlotProvider.
Subcomponents need to rely on some global APIs or data. For example, the actual rendered content of <Slot /> comes from the content of <AddOn /> collected by SlotProvider.

At this time, we need to use an intermediary as a medium to share data. Compared with the introduction of third-party modules such as redux, using Context directly can be more elegant.

Try the new Context API

Use the new version of Context API to transform the previous slot distribution component.

// SlotProvider.js

function getDisplayName (component) {
 return component.displayName || component.name || 'component'
}

export const SlotContext = React.createContext({
 requestAddOnRenderer: () => {}
})

const slotProviderHoC = (WrappedComponent) => {
 return class extends React.Component {
 static displayName = `SlotProvider(${getDisplayName(WrappedComponent)})`

 // Used to cache the content of each <AddOn /> addOnRenderers = {}
 
 requestAddOnRenderer = (name) => {
  if (!this.addOnRenderers[name]) {
  return undefined
  }
  return () => (
  this.addOnRenderers[name]
  )
 }

 render () {
  const {
  children,
  ...restProps
  } = this.props

  if (children) {
  // Cache the contents of <AddOn /> in kv mode const arr = React.Children.toArray(children)
  const nameChecked = []
  this.addOnRenderers = {}
  arr.forEach(item => {
   const itemType = item.type
   if (item.type.displayName === 'AddOn') {
   const slotName = item.props.slot || '$$default'
   // Ensure content uniqueness if (nameChecked.findIndex(item => item === stubName) !== -1) {
    throw new Error(`Slot(${slotName}) has been occupied`)
   }
   this.addOnRenderers[stubName] = item.props.children
   nameChecked.push(stubName)
   }
  })
  }
  
  return (
  <SlotContext.Provider value={
   requestAddOnRenderer: this.requestAddOnRenderer
   }>
   <WrappedComponent {...restProps} />
  </SlotContext.Provider>
  )
 }
 }
}

export const SlotProvider = slotProviderHoC

The previous childContextTypes and getChildContext() have been removed. Apart from some local adjustments, there are no major changes to the overall core.

// Slot.js

import { SlotContext } from './SlotProvider.js'

const Slot = ({ name, children }) => {
 return (
 <SlotContext.Consumer>
  {(context) => {
  const addOnRenderer = requestAddOnRenderer(name)
   return (addOnRenderer && addOnRenderer()) ||
   children ||
   null
  }}
 </SlotContext.Consumer>
 )
}

Slot.displayName = 'Slot'
Slot.propTypes = { name: PropTypes.string }
Slot.defaultProps = { name: '$$default' }

Because Context was previously used in the producer-consumer mode, and the component itself was relatively simple, there was not much difference after the transformation using the new API.

Summarize

Compared with props and state, React's Context can realize cross-level component communication.
The use of Context API is based on the producer-consumer model. On the producer side, it is declared through the component static property childContextTypes, and then the Context object is created through the instance method getChildContext(). On the consumer side, apply for the Context properties to be used through the component static property contextTypes, and then access the Context properties through the instance context.
Using Context requires more thought. It is not recommended to use Context in App. However, if you can ensure the cohesion of components, controllability and maintainability during component development, do not destroy the dependencies of the component tree, and have a small impact, you can consider using Context to solve some problems.
Exposing the API through Context may bring convenience to solving some problems to a certain extent, but I personally think it is not a good practice and needs to be cautious.
The old version of Context updates rely on setState(), which is unreliable, but this problem has been solved in the new version of the API.
You can think of Context as the scope of a component, but you need to pay attention to the controllability and scope of influence of Context. Before using it, analyze whether it is really necessary to use it to avoid some side effects caused by excessive use.
Context can be used as a medium to share data at the App level or component level.
When designing and developing a component, if this component requires the association and combination of multiple components, using Context may be more elegant.

The above is my sharing content. If there are any deficiencies or errors, you are welcome to criticize and correct me.

References

Context - https://reactjs.org/docs/context.html
React 16.3 is here: with a brand new Context API - http://cnodejs.org/topic/5a7bd5c4497a08f571384f03
Content Distribution with Slots - https://vuejs.org/v2/guide/components.html#Content-Distribution-with-Slots

This is the end of this article about my understanding and application of React Context. For more relevant React Context content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!

You may also be interested in: