Generated by 🚫 dangerJS

This solves part of the issue, but the second issue is that we rely on the correct props being resolved in React.createElement. Seems like there will need to be a check for lazy elements so that when a Fiber is created it's created with the resolved default props as well.

The obvious solution is adding a check to createElement for REACT_LAZY_TYPE, but that's a pretty hot path.

but the second issue is that we rely on the correct props being resolved in React.createElement

When you say "we rely" what do you mean exactly? Rely in what way?

Seems like there will need to be a check for lazy elements so that when a Fiber is created it's created with the resolved default props as well.

I don't understand how this could be possible. If the component is lazy, we don't have its default props at first, do we? We're waiting for it to load.

I'll continue this in #14108

When you say "we rely" what do you mean exactly? Rely in what way?

Default props are resolved in React.createElement. It's assumed that the element will have the resolved props at that point.

I don't understand how this could be possible. If the component is lazy, we don't have its default props at first, do we? We're waiting for it to load.

The initial load happens inside mountLazyComponent. At that point the default props aren't available, but it suspends and retries and eventually it calls resolveDefaultProps. It passes those resolved props to the corresponding update{Type}Component which is why the props are correct in the constructor and other lifecycle methods called at that point.

It was still broken for the initial commit phase, as props get read from the workInProgress. Setting pendingProps to the resolved props fixes that part of the issue.

Even then, it's still broken for updates. In React.createElement the lazy component has been fully resolved, but the default props are not parsed because it checks type.defaultProps and type is not the resolved component. When the workInProgress is created from the element it uses element.props.

My conclusion was that, at some point in the update path, we'd need to check the type and resolve the default props. I was trying to find the right place for this so that non-lazy components didn't incur the cost of calling resolveDefaultProps as well, but it wasn't clear where that would be for updates.

I was thinking it would be a similar solution to how we handle props with fragments

but the default props are not parsed because it checks type.defaultProps and type is not the resolved component

Would fiber.elementType work then?

(Feel free to push to my branch in #14108)

Would fiber.elementType work then?

We could check fiber.elementType before calling createWorkInProgress and then call resolveDefaultProps with pendingProps if it's a lazy component, but I was concerned about adding a property check there since it's a hot path for all element types.