Type error in Document.getInitialProps?

[benallfree]

Bug report

Describe the bug

I noticed that the definition of getInitialProps could be more expressive.

export default class Document<P = {}> extends Component<DocumentProps & P> {
    static getInitialProps(ctx: DocumentContext): Promise<DocumentInitialProps>;
}

I think it should be <DocumentInitialProps & P>

[justincy]

I don't think so. I believe that P represents the props passed in via attributes in JSX. They shouldn't be returned by getInitialProps.

[benallfree]

@justincy Thanks for the feedback.

It looks to me like P is intended to specify custom props passed into the component, isn't that what getInitialProps does? How can the props from getInitialProps be strongly typed instead of any, and how can they be strongly typed when the are passed in?

I had a typo above, I meant

    static getInitialProps(ctx: DocumentContext): Promise<DocumentInitialProps & P>;
                                                                               ^^^

[justincy]

It looks to me like P is intended to specify custom props passed into the component, isn't that what getInitialProps does?

Sort of. They both get passed into the component, but their source is different. P represents custom props from JSX. getInitialProps can return anything, and that data gets passed to the component as props as well, but it's not from JSX.

Perhaps you're hinting at the need for Document (and App, for that matter) to have a second generic that represents the type of data returned from getInitialProps like NextPage has.

https://github.com/zeit/next.js/blob/97a6b64f83fe1044a1446385ec8cb0efc7a77bd0/packages/next/types/index.d.ts#L43

[benallfree]

Yes, that might be helpful.

Is IP for initialProps? I still don’t understand why the source of the props is an important distinction. Is there a use case or example you can guide me to that demonstrates a situation where the interface should change based on context? That seems to oppose the very goal of interfaces.

[benallfree]

Put another way, when is it ever okay for getInitialProps to return props that violate the component’s interface?

[justincy]

Great questions. You are right that getInitialProps cannot returns props which violate the component's interface. The component's interface is a union of two types: props from JSX (often denoted as P in Next types) and props returned by getInitialProps. The reason why it's useful to distinguish their source is that P props are not returned by getInitialProps and props returned by getInitialProps should not be passed in via JSX. So you get type checking in both places.

Did I explain that well?

[justincy]

That's how I understand it, but I could be wrong.

[justincy]

But as I think about it, we never use Document, App, or Pages directly in JSX because Next just takes care of it for us, so I don't think I actually know what the purpose of P is.

[benallfree]

Yes you did, thank you. I understand the point you're making, but it seems to me that getInitialProps is only called on top-level page components and those are never instantiated via JSX -- ah you just left a comment to my point :)

So I'm back to thinking that the custom props type for Document and App should match the props that getInitialProps returns. They should be the same interface, IMHO.

And more generally, to me the purpose of an interface is to decouple a component from its contextual usage, and for that reason, the props are the props regardless of how they are initialized (JSX, SSR, Redux, whatever else).