Dont recreate maked context unless unmasked context changes

[bvaughn]

The problem

Fiber memoizes the merged context object for context-providers but does not memoize the masked context object. This caused componentWillReceiveProps to be called tpo frequently for context consumers which can result in infinite loops (eg if componentWillReceiveProps() calls setState()).

A minimal reproduction of one such infinite loop has been added as a test. It looks a little silly but it is greatly reduced from a bug I was investigating in a larger, real-world app.

The proposed solution

Given the way context is currently implemented, I think the only solution to this issue is to store memoized copies of both the unmasked and masked context objects in order to avoid unnecessarily recreating the masked context. (Stack already does something like this.)

Concerns

The solution in this PR is kind of awkward due to the facts that:

1. We probably want to cache this memoized context on a class instance rather than the Fiber to avoid adding 2 additional fields to all Fibers (because most won't consume context). Prior art is __reactInternalMemoizedMaskedChildContext.
2. The class instance doesn't yet exist the first time the masked context is created so we have to initially set the cached object outside of ReactFiberContext.

This change is kind of flimsy, but so is context in general at the moment (see this comment for elaboration).

Let's talk about it. 😄

[gaearon]

Seems fine to me. We can just remove masking later if we want to.

[acdlite]

In general, we shouldn't be using the instance to store memoized values because it's shared between both copies of the fiber, as we discussed. But since context is already broken for this purpose, maybe we don't need to care for now.

[bvaughn]

Agreed. That's why I mentioned the prior art. Seems like we need to clean up (or rethink) context at some point. This is just another band-aid.

[sebmarkbage]

This is very different from the provider since this is for every recipient. We expect there to be many more recipients and that those will update much more frequently than the providers.

Also this is adding more to the already broken solution that compares props equality. We should fix that with a tag rather than piling on.

[bvaughn]

This is very different from the provider since this is for every recipient. We expect there to be many more recipients and that those will update much more frequently than the providers.

I don't understand the first half of this comment. I'd love to talk about this with you when you're back in the office. Maybe we could just do that? Would be easier.

[acdlite]

@bvaughn __reactInternalMemoizedMaskedChildContext is on the provider (thing that provides context), not the consumer.

[bvaughn]

What I meant was that I don't understand the implications of what @sebmarkbage is saying.

This PR added caching for unmasked and masked context on the provider in order to avoid triggering unnecessarily calls to componentWillReceiveProps on child consumers. That was intentional.

Edit: (Aside from the fact that using the instance to cache values is hack and error-prone) is the concern that I'm caching this value on the wrong instance? As in I'm caching a value on an instance that doesn't actually originate with that instance.

[sebmarkbage]

Providers don't have masked contexts unless they're also receivers.

[sebmarkbage]

Are we doing this on every instance? That's probably not great.

[gaearon]

Oops, I missed this. 😞

[gaearon]

For the context, before this PR we used to only set the hidden field on the context consumers, not on all instances. The rationale is that only components that actually use the context should pay the price for it, not intermediate components.

[bvaughn]

Would it help to only track this on context consumers?

[gaearon]

Yes. (But ideally we shouldn't check if something is a consumer twice either.)

[gaearon]

Ideally we also shouldn't use __reactInternal[...] fields outside of FiberContext file. Not that it matters a lot but it’s hacky and I want to keep it contained.

[bvaughn]

I agree. I mentioned that as a hack in the PR description.

I could move the setting of that hidden field into a helper function inside of ReactFiberContext to at least keep the naming of the field there. Briefly considered doing that initially.

[bvaughn]

Is #8723 an improvement?

[bvaughn]

Yeah, I'm kind of cheating by caching the masked and unmasked context values on the receiver not the provider. It's not necessary for the provider to also be a receiver.