Idea: introduce `<Inject store>{(store) => ...` component, to mimic React.createContext's consumer

[danielkcz]

This is merely just to start a discussion, but it's finally released in React 16.3. I think this can bring a huge relieve to all that inject mess, especially when in TypeScript.

First and foremost, given how beautifully crafted this new API is, it doesn't necessarily need to be a part of mobx-react anymore, but it probably should just for a convenience of a newcomer.

export function createConsumer<T>(stores: T) {
  const { Consumer } = createContext<T>(stores)
  return Consumer
}

// just use as a component
const Consumer = createConsumer(myStores)
<Consumer>{stores => /* inferred type, awesome */}</Consumer>

An alternative approach using a context.Provider is for cases when provided value is not constant, eg. in this case when a shape of the stores need to change. Personally, I haven't found any use case where that would be needed, so I am not going to elaborate on that futher. Also it's worth noting that there is no limit on calling that createConsumer function multiple times to have additional consumers with a separate stores.

The Consumer component can be used to create HoC variant. I am not entirely sure if all that logic that's currently present there is still needed. At least a ref handling can be done properly with a new forwardRef API. It's almost astounding seeing how much hassle is needed for that compared to a simple render prop case. Either way, I am not feeling confident enought to handle that.

Note: Typescript definition for createContext and forwardRef should be merged soon.

[xogeny]

Just as a point of reference, I did implement a Provider/Consumer pair in my article about using React 16.3 Context with TypeScript. It seemed to work just fine.

One thing I found interesting about the new Context API is that you can provide a default value to the createContext function. What I had hoped was that if a default value is provided to createContext that you wouldn't necessarily need to provide one for the Provider. But the value prop for Provider is listed as mandatory in the current typings. Apparently, the way this is supposed to work is that the default value is used by the Consumer in the case that no Provider is present.

As I wrote in my article, I don't like the idea of a missing Provider. It seems like you are opening the door to some nasty silent failures. But some mobx users might like this because they could provide the store to the createContext call and then the Consumer is effectively just an injection point.

But I would add that it is pretty easy to create variations of the Context API. Ultimately, the mobx use cases might dictate some slightly different use cases and I suspect the new Context API will support whatever those might be (e.g., plucking specific variables out of the store as is current done with inject, IIRC).

[danielkcz]

One thing I found interesting about the new Context API is that you can provide a default value to the createContext function. What I had hoped was that if a default value is provided to createContext that you wouldn't necessarily need to provide one for the Provider.

Personally, I do consider the Provider more as a tool for tests. While in the app code you can often get away with just a Consumer that gives you a default value from createContext, in tests you can actually wrap a whole thing to Provider and change this value to eg. mocked value. Of course, same can be done if you use the Provider to wrap a whole app, but I am simply failing to see any benefit in that.

Perhaps my view is a bit skewed as I am so used to MobX observers, that changing some high-level prop does not feel right anymore. Why bother when a component can just observe values it cares about and gets updated accordingly?

[jason-henriksen]

To me, it actually feels like the existing mobx-react provider is better than the new API in 16.3. I guess I like that I can say

{this.props.MyDataStore.foo}

as opposed to
<Context.Consumer>{(MyDataStore)=>(

{MyDataStore.foo}

)</Context.Consumer>

please keep the existing API as much as possible. The extra consumer stuff in react 16.3 makes me think that it may not receive that much adoption. I certainly don't intend to do that much extra work every time I want to access a shared variable.

Is there some way to access that variable without the tag, that I'm not aware of? Could I type:
{Context.Consumer.MyDataStore.foo} ?

[danielkcz]

@jason-henriksen Your example is somewhat confusing. You cannot "just read" this.props.MyDataStore.foo without using inject HoC. For TypeScript users it's bit more clunky to use that HoC properly.

I think you are mixing two concerns together. The Provider is a perfectly simple piece of code (exposing contextTypes) and it will be mostly the same with a new API. What is going to be different (internally) is the consuming part. Currently you have to use inject or make a class component with childContextTypes on your own. Both are rather awkward imo and there is no other way.

With a new API, you have a nice render prop component (Consumer) as a base building block. It can be used directly like that or wrapped into HoC with a few lines of code and it will work the same way as you know now. There doesn't need to be any breaking change in mobx-react API surface as far as I know.

[jason-henriksen]

First off, I agree that it's primarily the internals of react-mobx would change. I'm just saying that I really like the current API and I hope it doesn't really need to change much. I'm also saying that I find the new 16.3 context API to have clunky example code.
(I can't speak to the TypeScript side of things. But, I'm sorry to hear that it's a hassle.)

It's true that I'm using the @Inject at the top of my class to provide the access for the provider. It's so innocuous that I'd almost forgotten it was there!

I don't immediately see an equally easy way to wrap a context class wrapper around a newly defined class. @Inject makes my life very easy. Maybe I'm spoiled by it?

I guess what I really don't want is a tag. I love @Inject and I'd be OK with a method I could call in the constructor which says "this class cares about this context object." A tag/method wrapper just doesn't fit anywhere easily and it looks uncomfortable to me, personally.

Of course, I don't think anyone at facebook really gives a whistle what I want and nor should they. I was just trying to say that I really like the way the current mobx-react handles it, that's all.

[danielkcz]

The inject can stay pretty much the same on the outside, I am sure of it. Same goes for the Provider. The major advantage of this change would be the addition of Consumer (could be named Injector or something) which can be used by folks who like render prop components and of course better TypeScript support. This Consumer will be also used in a new inject.

[mweststrate]

Closing for now, there is no immediate need to change to the new api for internals, nor is there any need to change the api to match createContext, because one can just use React.createContext in that case :)

[mweststrate]

Reopened, missed the last comment by @FredyC, I think an api that is compatible with Provider, but writes as could be useful indeed; primary question being: can this be typed correctly?

<Inject userStore authStore>
  {({userStore, authStore}) => <div>{userStore.name}</div>}
<Inject>

[jrmyio]

I tried Styled components v4 today, they are using the new "React.forwardRef". Whenever I wrap such a component in mobx's observer a few errors are thrown:
styled-components/styled-components#1969 (comment)

Is this related to this issue?