Hi!
it's more a feature request than a bug. unmaskAsNumber works as expected to reformat german number format to JS-Format.
With this option enabled unmask returns the value of the input field casted as number. This breaks the default behaviour of $('input[type="text"]').val() as this usually returns a string.
The "problem" I'm facing is that some libs are expecting a string (e.g. jQuery-form). Since they are doing some string operation on the fields - they crash (e.g. Uncaught TypeError: e(...).val(...).replace is not a function).
I think it shouldn't be inputmasks job to cast values, but I understand if you don't want to break current behaviour.
So I vote for a (weird sounding) option like "unmaskAsNumberString":
... (opts.unmaskAsNumberString ? processValue : Number(processValue) ) ) : processValue; ...
best regards and many thanks for your great work!
Arne
Hi! it's more a feature request than a bug. unmaskAsNumber works as expected to reformat german number format to JS-Format. With this option enabled unmask returns the value of the input field casted as number. This breaks the default behaviour of $('input[type="text"]').val() as this usually returns a string.
The "problem" I'm facing is that some libs are expecting a string (e.g. jQuery-form). Since they are doing some string operation on the fields - they crash (e.g. Uncaught TypeError: e(...).val(...).replace is not a function).
I think it shouldn't be inputmasks job to cast values, but I understand if you don't want to break current behaviour. So I vote for a (weird sounding) option like "unmaskAsNumberString": ... (opts.unmaskAsNumberString ? processValue : Number(processValue) ) ) : processValue; ...
best regards and many thanks for your great work! Arne