How does this method even work outside of render? (eg. constructor, lifecycle methods, etc)

[srcspider]

Since the pattern is that you have to have this consumer component, how do you get to the context when you're in the constructor exactly?

I'll give two examples of where you would want this.

Example 1: You want a simple state application

Given you have something like a Baobab tree, you want to make it available to your subtree so that components in the subtree can just use it (I gave state here as an example but it applies to anything really). Assuming components in the subtree have to "do stuff" with it how exactly do you do it?

The only way I see it with this new system is to start create THREE components every time you need to consume it: once to convert it to a higher order component, again to use the higher order componet to do the data manipulation and lastly you'd have your ui component.

The key point is that you want your subtree components to NOT GIVE A DAMN on what application state they're subscribed to. So if you say have a user component and several applications on the page, each with said user component, you want each component to work with the state passed down from the initialization code, not some shared mucked up state.

Example 2: You need to call up an arbitrary function.

So let's say I have some dispatch system, that given a "url" decides how to change the application, location history and so on.

And then I have various situations and components where I want to call this dispatcher. These may be simple or may be complex routines that require redirection to happen. Ideally what we want is for the top-most level to configure one of these dispatchers and all bottom levels to use the dispatcher they're given.

For simple cases such as a smart Anchor component that either invokes the dispatcher or acts as a regular anchor element, we can kind of suffer the silliness of having to wrap it all in a provider then bind it as an extra parameter in there. But once you start having the requirement for the dispatcher be somewhere that's a few calls down it just becomes a pain to deal with. Since now instead of simply being able to get to it easily whenever it needs to be passed to a function outside the component, every single call up to it has to have it binded over and over; likely just in case "eventually we might need it so god fodbid we have to change all the damn interfaces for every function"

---

Simple solution to the problem: the "consumer" needs to be easily usable in the constructor

Also, I might add, all of THIS is NOT a problem with the current system.

[trueadm]

What's this comment in relation to? I don't think you meant to make an issue here?

[srcspider]

@trueadm for some reason interpreted this as the "RFC repo" for the new context system, since it looked like you forked a template at first glance. My mistake.

I'm a bit confused. If this is not a repo for discussing the features then what is it? To my knowledge RFC stands for Request For Comments, term originating per the original http (?) specs if I recall.

I re-read the README, if I'm understanding correctly and not just anyone can comment on the designs (just submit designs), as the process section suggests, then don't call them RFCs.

[milesj]

@srcspider I'm pretty sure it's for submitting proposals (in which RFC is valid), not general questions.

[kyleshevlin]

@srcspider RFC stands for Request For Change. This repo is for submitting ideas to change React and discussing the merit of the proposed changes in order to determine whether they are implemented or not. There might be better venues to discuss your questions than here.

[gaearon]

In any case we're grateful for the questions. We'll address them in the blog post about the updates when it comes out.

[bvaughn]

Since the pattern is that you have to have this consumer component, how do you get to the context when you're in the constructor exactly?

Simple solution to the problem: the "consumer" needs to be easily usable in the constructor
Also, I might add, all of THIS is NOT a problem with the current system.

I don't fully understand what's you're describing, and I apologize if I'm misunderstanding what you're asking- but it seems like you might just be asking how to access a value provided by the new context API within the constructor of a class component? Is this right?

Before, you could do this like so:

class ExampleComponent extends React.Component {
  constructor(props, context) {
    super(props, context);

    // context.exampleValue;
  }
}

The way you can do this with the new context API is very similar:

// Pass it down as a prop
<ExampleContext.Consumer>
  {value => <ExampleComponent exampleValue={value} />}
</ExampleContext.Consumer>

class ExampleComponent extends React.Component {
  constructor(props) {
    super(props);

    // Then access it as a prop:
    // props.exampleValue
  }
}

[srcspider]

@kyleshevlin straight from their blog post:

https://reactjs.org/blog/2017/12/07/introducing-the-react-rfc-process.html

We’re adopting an RFC (“request for comments”) process for contributing ideas to React.

And this repos' readme,

The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project.

Also,
https://www.ietf.org/standards/rfcs/
https://en.wikipedia.org/wiki/Request_for_Comments

Though you are right that it can also stand for "Change Request," supposedly https://en.wikipedia.org/wiki/Change_request

[bvaughn]

@srcspider: Did I misunderstand what you were asking then?

[gaearon]

@srcspider The intention is to provide feedback while the RFC is open. The open RFCs are in this section. After an RFC is merged, you're still welcome to add feedback by creating other RFCs that address your problem. Hope this clarifies it a bit.

[srcspider]

@gaearon It does. Thanks.