There are two things here, I’ll respond to the referential identity thing first: unfortunately, yes, there is a small hack used in there. The reason for that is, without it, every H.get would also cause a re-render - that rightly sounds bizzarre, but it’s a consequence of get, modify, put etc. all being implemented by the state function required for MonadState. Since we didn’t want to require Eq on state, we put a reference check in to try to get the best of both worlds.
Putting a different state then putting it back certainly is one option 
. I’d probably add a cycle :: Int (or some name like that) to the state and increment that each time instead of putting the exact unmodified state back, as that’d force a render. Alternatively flipping a Boolean on and off would work, just something to trivially modify the state.
As for what is actually being done here - I wouldn’t recommend it. Changing the value in an input when the user is typing in it will reset the input cursor position. This is fine if someone is only “typing forwards” in the input, but can become very annoying if they’re trying to edit a value.
A browser-natively supported alternative is to use the pattern property on an input which allows input to be constrained to values that match a regex pattern.
If pattern isn’t expressive enough, I’d recommend having the state contain Either String ValidatedValue for the property, and then store the string when it’s invalid and display a message about why the input is invalid instead. I tend to take this approach generally, as at least you can communicate more clearly what a valid value looks like. 