Closed cgatesman closed 7 years ago
Afaik, It's inherit lower level library behavior. But i believe there is isDirty
method somewhere, which can be useful in your callback
It seems pretty grossly inefficient. I can't rely on just a dirty flag. A user could type a character then delete that character. Now it's flagged as dirty, but the content has not changed. This means instead of a dirty flag, I have to string comparison the entire content on every onChange
even though they may be just cursoring around in the text. If the text is extremely long, this could be very CPU intensive.
What is this "lower level library" you're referring to? It's just using a textarea. Seems like it is perhaps firing on keyup
which is incorrect. It should just fire on input propertychange
which I don't believe includes just cursoring around in the textarea.
What is this "lower level library" you're referring to?
The keyup
and change
, they are both inherited from jQuery.
It's just using a textarea. Seems like it is perhaps firing on keyup which is incorrect. It should just fire on input propertychange which I don't believe includes just cursoring around in the textarea.
This ought to be very simple. But unfortunately it isn't. keyup
maybe a terrible event for input detection, you got the point. But Cut/Paste via contextmenu unfortunately is also input, and so is backspace.
I haven't test the performance comparison of using keyup
against input
or propertychange
, but I'm sure we're looking at other issue here.
Cursoring around in a textarea should not be firing an
onChange
.