Is there a way to access new context api within ComponentDidMount?

[grillorafael]

We are building a react mapbox gl module and we use clone and inject props today.

We were looking into using the 16.2.0 context api but I saw that it will have a new one on 16.3.0 but I can’t seem to find a way to read context details
On componentDidMount lifecycle (which makes sense for me to use on the map implementation).

Is there a way around this ?

[grillorafael]

Adding a example that I'm trying to have this working: https://codesandbox.io/s/l20yn296w7

EDIT: Following the guidelines from https://github.com/reactjs/rfcs/blob/master/text/0002-new-version-of-context.md#class-based-api

[TrySound]

This is how it can be achieved with new api.

class BaseMapElement extends React.Component {
  componentDidMount() {
    console.log(this.props.context);
  }

  render() {
    return null;
  }
}

const MapElement = () => (
  <Context.Consumer>
    {context =>
      <BaseMapElement context={context} />
    }
  </Context.Consumer>
)

[grillorafael]

So the only way to access through componentDidMount is to redirect into Props?

Edit: Changed to componentDidMount

[jquense]

The higher order component that redirecs to props is a good pattern,but for cases where don't want the extra component usually wat I do is store the context value on the component instance like: this.contextValue = value then access it in the life cycle hooks. It's a bit ugly but that's ok generally I think since your opting out of the nicer, hoc, pattern as an optimization

[porfirioribeiro]

I'm facing the same dilemma.
There should be a easy way to access or call context in life-cycle methods.
We might need to initialize stuff, check and fetch data or even clean-up on unmount.
People are doing it now with the current supposedly broken context.
Yes it can be solved by wrapping our component in another component! But feels like a workaround more than a solution.

[gaearon]

store the context value on the component instance like: this.contextValue = value then access it in the life cycle hooks

I’m pretty sure this is unsafe in async mode. Please don’t do this. cc @acdlite

[grillorafael]

Yes it can be solved by wrapping our component in another component! But feels like a workaround more than a solution.

I agree with that. Would be nice to natively access through componentDidMount and componentWillUnmount to be able to initialize/cleanup things,

[acdlite]

In general, using instance vars to be clever and cheat the normal data flow is going to cause problems in async. Just don’t. It’s a bit confusing today, because instance vars are the only way to do certain things, like timers. Before we release async we’ll publish clearer recommendations — and one day we’ll have a new component API that doesn’t rely so much on instances.

tl;dr: Use a props indirection. And don’t worry too much about the extra component.

[jquense]

I’m pretty sure this is unsafe in async mode. Please don’t do this.

How would this be unsafe (and in what way)? It's faily unclear in all this talk about async mode, what "unsafe" means. It's starting to feel like a boogyman who behavior is irrational and unpredictable, which doesn't fill folks with a lot of assurance in a system that is generally liked for it's straightforward, easily understandable, data flow model. I feels like components are back in pre 0.13 land where they are magic objects again.

It's also easy to say "Just add another component", but that's often onerous, and introduces it's own category of bugs and challenges. I't starts to feel like folks have to invent abstractions over a react API in order to be "safe".

[jquense]

sorry ^ if the above sounds annoyed/angry, i didn't intend that tone! on a phhhhooone

[grillorafael]

It did sound angry haha but I get your point and I share your questions about how/why it will be unsafe

[gaearon]

It's starting to feel like a boogyman who behavior is irrational and unpredictable

I’m sorry, but we’ve been working on a guidance with specific suggestions for over a month now. Please give us time to collect and publish them as a blog post. It is also difficult to discuss without actual alphas to play with, which is also something we’ve been working hard on.

So we have to either not say anything at all, or warn in advance about things that won’t work well. We err on the side of warning but I can see how it can look like we’re making it more difficult for you. I’m sure that once the code is out and you can play with it, you’ll see what we mean, and it’ll make more sense.

How would this be unsafe (and in what way)?

Did you get a chance to watch my talk? This will be a bit hard to explain if you haven’t seen the second part of it, because it wouldn’t be clear why we are doing this. So I’m asking you to watch it. I hope that my talk will convince you we’re aiming to solve a broad class of problems that plagued React since the beginning, and that these features are worth revisiting some assumptions we might have gotten used to.

Assuming you’ve seen the talk, here’s a more specific explanation about this particular case. In order to be able to “suspend” rendering like I showed in the demo, React needs to be able to call render() at any point in time, potentially with different props. For example if may set this.props and this.state to props from a new screen (that’s being loaded), call render, but then set it to old this.props and this.state when rendering in response to an interaction on the current version of the tree (e.g. if I press on something while the new screen is loading).

In async, the rule of thumb is: only lifecycles like componentDidMount, componentDidUpdate, and componentWillUnmount and ref callbacks execute at well-defined points in time with props and state that correspond to what’s on the screen. Luckily we only have a few other lifecycles that don’t neatly fit into this picture, and we are introducing better alternatives for them (getDerivedPropsFromState, getSnapshotBeforeUpdate). This will be a gradual migration. Again, it’s all going to be in the blog post.

Now to the root of this issue. In async mode, React doesn’t make guarantees about when and in which order it calls the render method. Which is really something React never guaranteed in the first place—it just happened to be the same order every time. Storing a field in render and then reading it in a lifecycle is not “safe” because you might store a field at the time React called render with different props (such as for a suspended tree that isn’t ready yet).

[gaearon]

There should be a easy way to access or call context in life-cycle methods.
Yes it can be solved by wrapping our component in another component! But feels like a workaround more than a solution.

I understand it feels like it’s an extra wrapper, but it’s what makes the new context fast. If we didn’t have explicit wrapper nodes in the tree we wouldn’t be able to quickly “find” components that need to update.

If you need to access context in lifecycle, take it as a prop.

class Button extends React.Component {
  componentDidMount() {
    alert(this.props.theme);
  }

  render() {
    const { theme, children } = this.props;
    return (
      <button className={theme ? 'dark' : 'light'}>
        {children}
      </button>
    );
  }
}

export default React.forwardRef((props, ref) => (
  <ThemeContext.Consumer>
    {theme => <Button {...props} theme={theme} ref={ref} />}
  </ThemeContext.Consumer>
));

This is almost the same amount of lines as a contextTypes definition.

[bvaughn]

Yes it can be solved by wrapping our component in another component! But feels like a workaround more than a solution.

Just wanted to second what Dan said that the child function / render prop approach is the official API for the new context- so please use it and let React worry about making sure it's fast. (It will be!)

How would this be unsafe (and in what way)?

The draft Strict Mode docs also touch on some of why mutating the instance (which is just another type of side effect) is dangerous in async mode.