Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Mithril 0.2.0 textarea not updating when expected if not storing its value to a model #701
The test seems to show that a textarea is not being updated to overwrite its user-entered contents unless the related model value itself changes (which then causes Mithril to decide the textarea's value is out-of-date). This means the textarea could potentially get out of step with what is in the model. It seems possible that textareas only work OK in most in-practice cases because their models are constantly changing to different values as they are edited and store those changes into the model? Granted, the behavior demonstrated in the fiddle may not be a common situation because the behavior will only manifest itself if an application does not respond to every change in a textarea's contents in a way that updates the value of the textarea. However, as the fiddle shows, a regular text input works as one might expect, so there is an inconsistency here.
In the application I'm working on, this issue manifested when initially setting a item-detail textarea to an empty string via value and then manually entered text into the textarea via the browser. The application code (intentionally) discarded the change because an associated display item was not yet selected. So, the textarea's internal value was not being updated by the application in the view method as the textarea's text was changed by the user, as would otherwise normally be the case. (Yes, the textarea should ideally be disabled if the data is not available -- I just noticed this issue while working towards that ideal.) The issue became apparent when a subsequent change in the data model by setting value on the textarea again to an empty string for an available data item was not reflected in the application GUI. I think this is because Mithril 0.2.0 apparently decided that the textarea must still be blank because its value was originally set that way (despite its actual contents being changed by the user). When I replaced the textarea with a text input, the application worked as I initially expected, with the displayed value in the input cleared when selecting an available item.
The solution is probably similar to what ldimi outlined. In setAttributes, the test:
should probably be:
I say "probably" because since a textarea can take internal text elements, as well as be set by "value", I'm not sure about any other implications in that other case. I tested the change locally and with the change the textarea updated as I expected (back to empty when tabbing out caused a redraw). But I was only setting the value, not the internal text components. Also, I'm not sure what the performance implications are. I'd agree this is an edge case, since most applications would presumably have a valid model to store data in that closely tracks the textarea's current contents, and so Mithril 0.2.0's current updating strategy might be good enough in that case. However, it is also an edge case that took hours of troubleshooting and research to isolate down to this test case and this understanding -- so ideally others could be spared that, since this edge case may be a common situation while developing an app incrementally, even if a finished app may avoid it. Still, on the plus side, I know a bit more about Mithril internals now from debugging this. :-) And a big advantage of Mithril is that it is much easier to debug than many other GUI frameworks.
Also, I wonder if this issue is to any extent a regression error introduce by removing the check in setAttributes of: "|| node === window.document.activeElement" which was present in Mithril 0.1.14? Presumably that might have forced the update of a recently-used textarea's value when it was the current widget? I'm not saying to go back to that approach, just that textarea updating might have worked differently back then.
referenced this issue
Jun 30, 2015
It looks like issue #691 related to checkboxes may have the same cause as this one. It is also possible that radiobuttons, and selects may have this issue too (since they also have either checked or a value that would need to be tracked). I outlined a somewhat more complex test and set code in a response to that issue which includes those other types.
@impinball The current released version of Mithril at GitHub seems to be 0.2.0. That is the one which demonstrates the issue and which I am using myself. I am not aware of a Mithril 0.4 being available yet, or even in development?
BTW, we are discussing the root of this issue further in issue #691 as it applies to almost any user-modifiable property including checked, scrollTop, selectionStart, etc.. A big decision is whether this behavior is a "feature" or a "bug" and how to move forward on changing it and/or documenting it.