type Provider<T> = ComponentType<{

type Consumer<T> = ComponentType<{

missing field:

unstable_observedBits?: number;

createContext has an optional second argument:

calculateChangedBits?: (prev: T, next: T) => number

It should be possible to call createContext() to create one with defaultValue of undefined.

function createContext<T>(): Context<T|undefined> override? This is one of those that look like the antipattern warned against in the docs, but I think it's correct to use here, similar to a collection constructor.

Hmm. I'm confused here. Calling createContext() (i.e., no arguments) would require the defaultValue to be optional. Otherwise you'd need to do an explicit createContext(undefined). Also, since T can be anything, I don't understand T|undefined.

FYI, I address this case of optional default values in my article on the new Context API (using the typings as they stand here, but wrapping them in one additional layer). Also note that, in my opinion (see article), it isn't just about making the default value optional. But again, I used these typings without issue.

16.3 released today and the docs seem to indicate @Kovensky is correct here — they use ‘createContext’ without args so it must be a correct usage. I’ll take a look at updating later today.

https://reactjs.org/docs/context.html

OK, rebased this post merge conflict.

Spent some time with this tonight and it looks like the behavior of the final API is that
createContext() gives you a context object where _defaultValue is undefined.

createContext('foo') gives you a context object where _defaultValue is foo

Given that, I'm a bit confused as to the correct typing for createContext() with no params. I tried the overload @Kovensky mentioned but doing so types the resulting RenderProps function args with {} or undefined, which I don't think is correct.

I suspect the overload closest to the API's usage would be

function createContext(): Context<any>

Which completely gives up type safety for RenderProps function but at least allows it to be used. {} or undefined doesn't allow you to still give, say, an anonymous object in the Provider's value field and still be able to retrieve it later in the RenderProps.

If anyone has any opinions on this they'd be welcome.

Yup, I'm just saying that we shouldn't want to correct that behavior, because you can always use Consumer not paired with a Provider so the value of T should not change even if you later pass in the value as a prop to Provider.

I.e. if you create the context with the default value, you are always guaranteed to have a defined value wherever you use Consumer (even not as a descendant of Provider), but once you create the context without a default value, you are not guaranteed that defined value unless you wrap the Consumer inside a Provider, which wouldn't be able to be statically analyzed before runtime.

I'm agreeing with you that it's unfortunate that we'll always have to check for undefined, but I think that should be the way the interface is structured due to the lack of compile-time guarantees of the consumer value

Well, in your first example you had the comment there /* value here will be defined, even though it's typed as optional */ and that was what's confused me the most. As you have said now, you will have to check for undefined either way. I understand now.

I see a bit of problem arising here. Developers are generally lazy and we might end up with pattern like this.

interface MyContextType { myValue: string }
const Context = createContext<MyContextType>()

<Context.Consumer>{value => { 
  <div>{value!.myValue.toUpperCase()}</div> // <-- notice the "!" mark there
</Context.Consumer>

That might be a good source of runtime errors (and blaming TypeScript/React for it) in case someone really forgets to add the Provider. It's true that if anyone is using ! it's for own risk, but there are people that might just copy&paste and then be surprised.

What about this approach? Would this work the same way? I am not sure if it's a correct syntax, but you get the gist. This would at least allow to override this undefined type in case someone knows what they are doing.

function createContext<T, S = T | undefined>(): Context<S>;

Hmm.. it might not be immediately clear to the user why the second generic type param may be used, and they'll have to dig into the type defs to actually find out how they resolve.

With my suggestion (the two overloads), creating context with a default param will assert the value in the consumer to be always be defined:

interface ContextProps {
  foo: string
  bar?: number
}

// note the default values passed in as the first parameter
const Context = createContext<Props>({ foo: 'foo' }) // typed as Props
const OtherContext = createContext({ foo: 'foo' }) // inferred to be type { foo: string }

// even without a Provider it is still typed to be required
const app = (
  <App>
    <Context.Consumer>
      {( value ) => /* value is typed to be Props here, no need to check for undefined */ }
    </Context.Consumer>
    <Context.Consumer>
      {( value ) => /* value is typed to be { foo: string } here, no need to check for undefined */ }
    </Context.Consumer>
  </App>
)

in this case, all you need as a type consumer to override the undefined behavior is to just provide a default value, the type inference will work for you or you can explicitly set the generic type parameter, and as long as the default value is passed in as a parameter, the consumer render props will always be defined

@ferdaber I'm trying to use the TypeScript 2.8 features you mentioned in this definition, but it looks like that's not possible yet?

I've updated the headers to // TypeScript Version: 2.8 but that results in a linting error.

According to this comment, we can only use TypeScript up to 2.7 right now, so I may not be able to use the definition you specify.

#24586 (comment)

ah, that's too bad, we'll keep it in the backburner then

I'm not sure these should be ComponentType; similarly to a Fragment, they can't actually be constructed, don't have a propTypes property, etc.

Why do you say they can't be constructed? That's exactly how they are used (or perhaps I'm misunderstanding what you mean by "constructed").

@Kovensky do you have a suggestion for what types they should be?

By "constructed" I mean given as argument to new. They're not even functions, as you can see in their definition, but unfortunately TSC doesn't support that 😞

I guess we're stuck with ComponentType here, at least until TSC is updated to use the overloads of React.createElement for JSX type checking.

microsoft/TypeScript#21699

It may be worthwhile to refactor the props interface of Consumer and Provider in case those props are spread from another place.

@ferdaber I'm not sure I understand the specific refactoring you want here. Could you elaborate?

I'm talking about refactoring the props as their own exported interface like this:

interface ConsumerProps<T> {
  children(value: T): ReactNode,
  unstable_observedBits?: number
}
interface ProviderProps<T> {
  children?: ReactNode
  // if you choose to use my suggestion, otherwise just T
  value: T extends undefined ? never : T 
}

// this way a consumer of the type can import `ConsumerProps` and `ProviderProps` for other purposes
type Consumer<T> = ComponentType<ConsumerProps<T>>
type Provider<T> = ComponentType<ProviderProps<T>>

Hmmm.. When I try that, in the test code proposed below it no longer is able to determine the type of value:

const ContextRenderPropsConsumerComponent = (
    <ContextWithDefaultValue.Consumer>
        {value => value.assert} // <--- Value here is now "any" with the props refactor
    </ContextWithDefaultValue.Consumer>
);

See the test example below for the full proposed test code.

@ferdaber It looks like the refactoring you proposed might cause some issues as well, listed in the comment above. Do you see a way around them?

odd... I tested it out and it works fine for me, these are my relevant snippets (I copied your test code as-is):

// react/index.d.ts

    interface ProviderProps<T> {
        value: T;
        children?: ReactNode;
    }

    interface ConsumerProps<T> {
        children: (value: T) => ReactNode;
        unstable_observedBits?: number;
    }

    type Provider<T> = ComponentType<ProviderProps<T>>;
    type Consumer<T> = ComponentType<ConsumerProps<T>>;
    interface Context<T> {
        Provider: Provider<T>;
        Consumer: Consumer<T>;
    }
    function createContext<T>(
        defaultValue: T,
        calculateChangedBits?: (prev: T, next: T) => number
    ): Context<T>;
    function createContext<T>(): Context<T | undefined>;

// react/test/tsx.tsx

import React from '.'

const RenderPropsContext = React.createContext('defaultValue');

interface RenderPropsContextTest {
    assert: boolean;
}

const ContextWithDefaultValue = React.createContext<RenderPropsContextTest>({ assert: true });
const ContextWithoutDefaultValue = React.createContext<RenderPropsContextTest>();

const ContextRenderPropsConsumerComponent = (
    <ContextWithDefaultValue.Consumer>
        {value => value.assert}
    </ContextWithDefaultValue.Consumer>
);

const ContextRenderPropsProviderConsumerComponent = (
    <ContextWithoutDefaultValue.Provider value={{ assert: true }}>
        <ContextWithoutDefaultValue.Consumer>
            {value => value.assert}
        </ContextWithoutDefaultValue.Consumer>
    </ContextWithoutDefaultValue.Provider>
); // $ExpectError

@scally wrote:

When I try that, in the test code proposed below it no longer is able to determine the type of value:

perhaps that was an IDE bug? There are cases where Webstorm & IntelliJ IDEA don't show inferred argument type correctly (claims it is any), but when used incorrectly it still emits error with message mentioning correct type of the argument

I think this is the way too simple test to cover the changes. I would propose following, but I am not entirely sure how to run these tests, so there might some mistake (or several)

interface ContextTest = {
  assert: boolean
}
const ContextWithValue = React.createContext<ContextTest>({ assert: true })
const ContextWithoutValue = React.createContext<ContextTest>()

<ContextWithValue.Context>{value => value.assert}</ContextWithValue.Context>

<ContextWithoutValue.Provider value={{ assert: true }}>
  <ContextWithoutValue.Context>{value => value.assert}</ContextWithoutValue.Context>
</ContextWithoutValue.Provider>

@FredyC I'm not sure myself. The test files here don't seem to be assertion-style tests so much as a sandbox to prove that the typings work without syntax errors.

I agree that there could be more code here exercising both context scenarios (with and without defaults), but I don't know that they should be executable as none of the rest of the code in this file seems to be.

Well yes, tests code is not executed, because you're testing types, not React's behavior.
But tests shouldn't always be positive, if you think that there might be some usage that is not correct, but could be assumed as correct one.

What you have to do for failing tests is add // $ExpectError line immediately before the test line. More about that in DT readme:
https://github.com/DefinitelyTyped/DefinitelyTyped#lint
And dtslint readme:
https://github.com/Microsoft/dtslint#write-tests

@scally Are you willing to try that? Perhaps it's overkill for such relatively simple thing. It's your call.

@FredyC Yes, I'll try it out and see where I get with it.

I am trying something like this:

const RenderPropsContext = React.createContext('defaultValue');

interface RenderPropsContextTest {
    assert: boolean;
}

const ContextWithDefaultValue = React.createContext<RenderPropsContextTest>({ assert: true });
const ContextWithoutDefaultValue = React.createContext<RenderPropsContextTest>();

const ContextRenderPropsConsumerComponent = (
    <ContextWithDefaultValue.Consumer>
        {value => value.assert}
    </ContextWithDefaultValue.Consumer>
);

const ContextRenderPropsProviderConsumerComponent = (
    <ContextWithoutDefaultValue.Provider value={{ assert: true }}>
        <ContextWithoutDefaultValue.Consumer>
            {value => value.assert}
        </ContextWithoutDefaultValue.Consumer>
    </ContextWithoutDefaultValue.Provider>
); // $ExpectError

@FredyC Are these tests sufficient for what you feel should be achieved here?

Strange that the error is in the full statement instead of in the argument to Consumer, but seems to be the case.

An additional non-erroring test where the argument is value => value === undefined ? null : value.assert would also help demonstrate it.

There's one last confirmation I'd like to take; if the Context is created with a default value, will the Consumer receive that value even if it's not put inside its Provider in the tree? 🤔 looks at source

EDIT: The context's context has a copy of the default argument as its value, and it's only overwritten by the reconciler if the Provider is present. It's also restored to its original value once the Provider tree has been processed. So indeed it can only be undefined if you passed something that can be undefined (or nothing) to the createContext call.

Should the children be made mandatory? Not much point in a Provider without any children.

Would it really matter since ReactNode already accounts for undefined? I can see a scenario where someone may not render an app while waiting for an API result but would still like to layer a context provider on top of it (undefined or null children)

Note that ReactNode is wrong altogether, it should not include undefined. See this #23422 (review) from Dan. It should be better eventually when this is resolved ... microsoft/TypeScript#21699.

Yeah, ReactNode is definitely wrong. If you actually use ReactNode anywhere, you'll get a warning from React.

I think the only time it doesn't warn is if you put it as an array element, but otherwise it's a warning.

It has to be ReactNode due to the above TypeScript issue though, otherwise it's impossible to use React with noImplicitAny. After the above issue is resolved this and many more types can be cleaned up but right now there is no option.

Side note, I do have a custom alias for this so I can actually have render prop SFC components and I am ignoring the type from ofic. typings. declare type ReactNode = React.ReactElement<any> | null. When this is resolved correctly, I can easily update this alias. It's not really useful here, but works well otherwise :)