fix: further resolve type of async components

[dwirz]

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
• Build (npm run build) was run locally for affected output targets
• Tests (npm test) were run locally and passed
• Prettier (npm run prettier) was run locally and passed

Pull request type

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

Issue URL: #561

What is the new behavior?

see Issue

Does this introduce a breaking change?

• Yes
• No

Other information

None.

[christian-bromann]

Great enhancement 👏 one comment though 🤔

[christian-bromann]

Wouldn't it be better to type the input value as unknown, same with other checks further below?

Suggested change

	const isEmpty = (value: any): value is null | undefined => value === null || value === undefined;
	const isEmpty = (value: unknown): value is null | undefined => value === null || value === undefined;

[dwirz]

@christian-bromann I updated all the type guards to use unknown, which definitely makes sense and also makes them more robust since it requires more thorough checks. 👍

As mentioned in #563, the current PR includes everything and covers more React cases. However, since I rewrote the entire function and there aren’t as many tests as in the Stencil repo, I can’t be entirely sure I’ve covered all cases. That said, I’m pretty confident—all cases of ReactNode-typing are handled. The only potential issue is with the _payload stuff.

So feel free to either close this and merge the other PR or vice versa. Up to you – either change would solve the issue. 🙂

[christian-bromann]

LGTM 👍

[christian-bromann]

I am planning to release all output targets today or tomorrow. Thanks again for your contribution!