Inconsistent defaultProps behavior in debug / no debug mode

[djaonourside]

It's not picked up default props if they aren't passed from parent component in no debug mode. Maybe react inlining problem:
https://try.haxe.org/#1489A

[elsassph]

@kLabz I'm looking at the defaultProps handling and it looks like components with default props aren't de-optimised but instead the default props are added as a spread - looks like your change?

[elsassph]

Ooooh I got it @djaonourside

When inlined, the defaultProps are added as spread and plucked to remove the props passed at compile time. Effectively, if props.color has an undefined value the component won't get the default value because of inlining.

@kLabz do you have an idea on how to solve this? React.createComponent will pick default props if the value is undefined at run time.

[kLabz]

I'm not sure what change you are talking about.

I handled the issue in react-next (last 4 commits here -- diff) but haven't had time to extract it in a PR here yet. I think the issue has always existed here, since the behavior is different at its core: in haxe-react we use the default prop if the prop is not passed while reactjs uses the default prop for every prop that as undefined as a value.

So if we end up passing undefined (when passing a prop from a component to another for example) we have a different behavior.

[elsassph]

I'm not sure what change you are talking about.

Originally I was de-optimising components with default props completely, so it was going through React.createComponent even for prod builds.

[kLabz]

I have no memory of either components being de-optimised when they had default props or changing anything about that.

Original implementation seemed to already have the issue.

[elsassph]

@kLabz you're right, it's from my original code 😅. I guess the solution is to never remove fields from defaultProps.

[kLabz]

Doesn't work either, if you pass undefined as prop it will overwrite the default prop.

[elsassph]

Damn you can overwrite with undefined :/