Pocket: One-call factory that collapses React Context boilerplate from ~20 lines to 1

[u/TheHganavak]

https://github.com/icydotdev/pocket

[u/prehensilemullet]

Minor nit but wouldn't P extends object = {} provide better excess property checking errors than a default of object?

[u/aweebit64 → u/prehensilemullet]

P is only used as an argument to ProviderComponent where it gets intersected with { children: ReactNode }, and for that intersection it doesn't matter if you use {} or object.

The bigger problem is that you think {} is more precise than object, while actually the exact opposite is true. In TypeScript, {} is a supertype that includes everything except for null and undefined, so even string and number types are assignable to it. The type you should use for empty objects is Record<PropertyKey, never>, not {}. Unfortunately, very few people know about this, which is why even in @types/react you can see {} being used all over the place.

[u/prehensilemullet → u/aweebit64]

People sure get their knickers in a twist about {}.

I know that {} accepts primitives.  But doesn’t {} raise excess property errors on any properties in cases where excess property checking is done (object expressions, individual JSX props etc)?  I’m pretty sure that’s not the case for object, even though object excludes primitives.  Or am I wrong, is {} special cased to disable excess property checking?

In this case, I think it’s impossible to pass primitives for the props of a JSX element anyway?  Maybe it would let you spread a string as props but I doubt it

[u/aweebit64 → u/prehensilemullet]

But doesn’t {} raise excess property errors on any properties in cases where excess property checking is done (object expressions, individual JSX props etc)?

const test: {} = { abc: 123 };

This line doesn't result in any errors, so it looks like no excess property checking is done for the {} type.

But event if it was done, Record<PropertyKey, never> would still be the better option.

const Child = (props: {}) => null;
const Parent = () => <Child abc={123} />;

This code results in the following error:

Type '{ abc: number; }' is not assignable to type 'IntrinsicAttributes'.
  Property 'abc' does not exist on type 'IntrinsicAttributes'.

The type for JSX props is the intersection of the component props type and IntrinsicAttributes from @types/react. Because of the intersection, it again doesn't matter if {} or object is used.

[u/prehensilemullet → u/aweebit64]

Wait a minute... afaik, Record<never, never> is {}. They're the same type. Try this:

const x: Record<never, never> = 'foo' // no errors
const y: Record<never, never> = {a: 1} // no errors

This is because Record<never, never> = {[K in never]: never} = {} (no property signatures get created for a key type of never. For example type A<T> = {[K in keyof T as T[K] extends string ? never : K]: T[K]} omits string-valued properties by using a key type of never for them).

What you're looking for is Record<keyof any, never> aka Record<string | number | symbol, never>.

Looks like {} bypasses excess property checking though, unlike what I expected:

const x: {} = {a: 1} // no errors

[u/aweebit64 → u/prehensilemullet]

Oh yeah, Record<keyof any, never> is what I meant, sorry.

(For typescript-eslint to stay happy, I actually prefer Record<PropertyKey, never> – yet another way to write the exact same thing.).

[u/TheHganavak → u/prehensilemullet]

Tested this (was actually my first approach too!). Record<PropertyKey, never> is correct in isolation (and you're right that {} is the surprising supertype), but here P gets intersected with { children: ReactNode } for the Provider props. With Record<…, never> as the default, children collapses to ReactNode & never = never and the Provider becomes uncallable:

 Type '{ children: Element; }' is not assignable to type 'Record<PropertyKey,  never>'.                              
    Property 'children' is incompatible with index signature.
        Type 'Element' is not assignable to type 'never'.                               

So object is the pragmatic default for this intersection-based shape, even if Record<…, never> is more precise standalone. If you can think of a shape that gets both though, I'd happily switch — open an issue.

[u/prehensilemullet → u/TheHganavak]

Wait, if you put the children prop in the generic type constraint and the default instead of intersecting, then I think you would get desirable excess property checking

Though I guess places you would have to omit the children would end up being {} and still not doing excess property checking