TodoMVC example: editing middle of existing todo moves cursor to end of input

[thomasboyt]

In the TodoMVC example linked in the readme, there's a nasty input bug - when you edit an existing todo, if your cursor is anywhere before the end of the input, it will jump to the end after you enter a character.

This is, of course, because the input is getting completely reset on render. I'm currently implementing a widget with an input field in React, the solution I'm going with is:

1. Store the cursor position in the state tree (the current value is update!ed from the onChange handler)
2. Use the did-update hook to call .setSelectionRange cursor-pos cursor-pos to reset back to the original position

This works, but isn't ideal, and is certainly some nasty boilerplate to be attaching to every input. Maybe there could be a special om/input component that could handle resetting the cursor on every change?

[swannodette]

Good catch. I don't think we should have to hack so much for something so basic and I see that the React version works just fine. I'll think about this some more and see what changes we have to make to avoid this issue.

[swannodette]

So I had a series of long conversations today with some React users on the React IRC channel, it seems like making a simpler wrapper for the DOM form elements that involve text entry is the way to go - here's a sketch of how to make it work http://jsfiddle.net/cc324/5/. Just waiting to hear from a React Dev if there are any obvious mistakes here.

[swannodette]

@spicyj suggested the following http://jsfiddle.net/spicyj/Kmf9r/, this appears to leverage more of the existing API.

[swannodette]

Fix in master based on @spicyj's fiddle.

[thomasboyt]

Awesome 👍

[cpetzold]

Ah, I ran in to this when playing around with inputs. I was using sablono, where this particular issue isn't fixed yet. It's not great that it'll also have to be solved within libraries that don't depend on om.

Do you think a library that takes hiccup forms in macros that convert to om.dom structure would be reasonable? I know @r0man wants to keep sablono dependency-free, otherwise I would say it would make sense there.

[swannodette]

@cpetzold I think you should open a ticket in sablono, or figure out what @r0man thinks the proper solution is.