Skip to content

Values lost when items being sorted contain an input field #13

Closed
johnwest80 opened this Issue Mar 28, 2012 · 16 comments

3 participants

@johnwest80

See the fiddle below. I took a sample of yours and added an input field to the sortable items. If you change the value and then drag the item to a different position, the value is lost.

http://jsfiddle.net/hw9B2/28/

Thoughts?

@mbest
mbest commented Mar 28, 2012

That's because the input field is actually removed and re-created after being dropped in the new location.

@johnwest80

Is this accepted behavior? It seems like a significant issue to me. Is it commonly accepted that input fields shouldn't be part of a drag and drop scenario?

@johnwest80

BTW, I came up with a workaround by having the input field bound to a property and forcing it to lose focus prior to the drag and dropping. In IE, it would lose its value even with a binding.

However, this workaround is a kludge, and doesn't work for non-bound input fields. So hopefully there will be a continued discussion about how it could be fixed in the library. Maybe not recreating the sorted item each time?

@rniemeyer
Owner

Hi @johnwest80
Can you describe your scenario a little bit further? In a typical KO app, you would have the input bound to an observable or property on your view model, so it would be represented in your data and naturally move with it as the items are sorted.

You may want to consider using valueUpdate: 'afterkeydown' to update the model as the user types.

The sortable binding works by moving the items in the observableArray to their new location and allowing KO to re-render them properly.

Would be happy to discuss this further though and try to find the best solution for your app.

@mbest
mbest commented Mar 29, 2012

The only way I see this could be supported would be if sortable directly handled the DOM updates and synchronization.

@johnwest80

It does work, mostly, with bound properties. But as my note above states, with IE (I tested IE9), if the input textbox still has focus when you drag, the updated value is lost after the drag action. Try the fiddle below in IE9, change a value, and, without tabbing out of the textbox, drag and drop it. The value will be lost. If you tab out first, the value is retained.

http://jsfiddle.net/hw9B2/27/

I did create a workaround by setting the focus to the window prior to the drag action, but anytime there's a hack to make things work, it seems like it's an opportunity to fix the problem at the source instead :).

@rniemeyer
Owner

I would not be opposed to adding something to the plugin to help with that particular issue (make sure field loses focus first). Using valueUpdate: 'afterkeydown' would be a choice as well, but that might not be appropriate for certain scenarios.

Although I can kind of see how it could work, I am not really in favor of having the plugin be responsible for the DOM synchronization itself.

@johnwest80

I can see your point about not doing the full DOM sync. I just added a sortable option as shown below to set focus to the window at the start of the operation. I'm not well-versed on events, so there's probably a better/more recommended way.

data-bind="sortable: {data: Policies, afterMove: updateMonthAfterMove, options: { start: function() {window.focus();} } }"

@rniemeyer
Owner

@johnwest80 my thought was to add a start handler similar to what you have in the plugin itself.

@johnwest80

So we'd still have to add a start function to set focus to the window ourselves, but it'd be at your library level instead of having to set options on jquery ui? Or would you bake in the window.focus yourself somehow?

@rniemeyer
Owner

No, I would pass a start handler (that sets focus) in as an option when the plugin initializes jQuery UI's sortable so it would just work without any additional configuration.

@rniemeyer rniemeyer added a commit that referenced this issue Mar 30, 2012
@rniemeyer force fields to lose focus when sorting starts to allow model updates…
… for issue #13. Wrap start/update options, if they are passed in binding.
ae0327e
@rniemeyer
Owner

The plugin now moves the focus automatically in the start function and wraps any start/update functions that are passed in as options now.

@rniemeyer rniemeyer closed this Mar 31, 2012
@johnwest80

I'm still having the same issue in Firefox. It happens on your sample, too. Add a new, change the value, then drag it. The value will revert to "New".

http://jsfiddle.net/rniemeyer/hw9B2/

@rniemeyer rniemeyer reopened this Apr 19, 2012
@rniemeyer
Owner

@johnwest80 - I'll take another look at this one when I get a chance and see what it takes to get FF to apply the change.

@rniemeyer
Owner

@johnwest80 it now fires the change event on the focused input. This seems to work fine across browsers.

@rniemeyer
Owner

Let me know if you see any additional issues.

@rniemeyer rniemeyer closed this Apr 25, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.