Values lost when items being sorted contain an input field

[rniemeyer]

Values lost when items being sorted contain an input field

[mbest]

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]

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]

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]

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]

@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]

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]

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

[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]

@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]

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

[rniemeyer]

Let me know if you see any additional issues.