Possible numericField bug (value lost when type of number changes)

[Dretch]

Hello, this library has a really nice design and docs, so thanks!

I have found what might be a bug (possibly I just misunderstand how things should be working, though).

I have a numericFieldV that stays in the same position in the widget tree, but sometimes contains an Integer value and other times contains a Float. The value is preserved as much as possible (using truncate/fromIntegral) when switching between the types.

I expected the value to stay showing (just changing whether it has a fractional part or not) when the type changes, but instead the numeric field loses the value and goes back to empty. This is demonstrated by this modification of the helloworld example: monomer-numeric-field-issue.zip

[fjvallarino]

Hi @Dretch!

I honestly hadn't considered this use case, and the reason it fails is because the internal state types do not match. When the user model changes, each widget is merged with the corresponding widget in the previous version of the tree. The old version of each widget is chosen based on position or nodeKey, also validating that their WidgetType matches (otherwise, the internal state types of the widgets would not match). Up to now, numericField set its WidgetType to numericField, which usually works fine but, when the type of the handled value changes, the internal types do not match anymore and merge does not run (in your case, switching from Double to Int).

This branch's version appends the handled type to the WidgetKey, so numericField will set itself to numericField-Double or numericField-Int. This is all internal, and you don't need to change anything.

To test this change, you can modify your stack.yaml to use this specific commit:

- git: https://github.com/fjvallarino/monomer.git
  commit: ce9e660a1b7f5ede6df1576686b362aefe7927e8

Let me know if this works as expected!

Ideally, I will release a new version by the end of the year, including this change and a few other things I have pending.

[Dretch]

Thanks for the explanation and the fix @fjvallarino (that works great) 🥇