Update typescript definition for resolve.

[dawnmist]

Expanding the resolve definition allows it to work with react-redux's connected components. Addresses issue #62.

[codecov[bot]]

Codecov Report

Merging #63 into master will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #63   +/-   ##
=======================================
  Coverage   94.38%   94.38%           
=======================================
  Files           3        3           
  Lines          89       89           
  Branches       25       25           
=======================================
  Hits           84       84           
  Misses          5        5

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 94fc382...a209724. Read the comment docs.

[ctrlplusb]

Thanks for looking into this @dawnmist - my typescript knowledge is zil so I have been depending on help from others with this.

Before we consider merging this I'd like to get @bdoss's input here as his PR changed the resolve from:

resolve: () => Promise<React.Component<P>>;

to:

resolve: () => Promise<React.ComponentType<P>>;

It seems to me that returning ReactNode sounds good as it's a subset of the Component types right but would like a second opinion. :)

[bdoss]

I think this is due to the autoResolveES2015Default option of the asyncComponent definition. It defaults to true, so it's hiding that implementation detail from the TypeScript compiler. I've been manually resolving like this:

resolve: () => import('MyComp').then(x => x.default)

It keep the compiler happy so it doesn't think you're trying to do anything silly. The advantage with using ComponentType<T> being that when you import the async component elsewhere for use as a JSX element, the TypeScript compiler can check and give suggestions on props.

Edit: I gave another look over your mods to the type definition and see that with your change to the resolve method you would still gain the ability to get prop checks/suggestions (if you explicitly provide your props Type) when importing the async component, while sacrificing the ability to properly type check the resolve callback itself. This would allow interoperability with the autoResolveES2015Default as you've demonstrated, but albeit with a trade off on a more generic (and I'm not sure semantically correct) definition.