fix(shared): improve toNumber

[Bigfish8]

fix #4370

[LinusBorg]

I don't think this is a real fix/solution for #4370.

While it would improve problems in converting numbers, the real issue is that _setAttrs in the custom element class doesn't respect the component's prop type. it should not convert it to a number if the component expects a string.

[Bigfish8]

I don't think this is a real fix/solution for #4370.

While it would improve problems in converting numbers, the real issue is that _setAttrs in the custom element class doesn't respect the component's prop type. it should not convert it to a number if the component expects a string.

Thanks for the review！

In fact, I partly agree with you.But I think props in component is designed to validate type rather than change type.
Even though I think toNumber here is unnecessary.Because web custom element is designed to use even without a framework.
So the behavior should be consistent with web standards.The toNumber conversion in fact is unexpected.The attrs which is passed in should always be String.

Maybe I should close this PR.

[LinusBorg]

But I think props in component is designed to validate type rather than change type.

I agree with this - but the wc wrapper could cast strings to numbers if the component expects a number for a given prop.

[posva]

This shared function toNumber() is also used in other places like v-model so I don't think it's a good idea to change its behavior

[Bigfish8]

This shared function toNumber() is also used in other places like v-model so I don't think it's a good idea to change its behavior

Thanks, I just notice that the Inconsistent between the PR and the docs.

This is often useful, because even with type="number", the value of HTML input elements always returns a string. If the value cannot be parsed with parseFloat(), then the original value is returned.

So indeed it seems not a good appoach.