Dom manipulation that occurs after ui-sortable compiles is not sorted

[Lorless]

I have a situation where a plugin is initialised in each of the repeated elements in my ui-sortable. It seems that any content manipulation made after ui-sortable runs is not taken into account. If you edit the html and then re-order an element the edited html remains in place. It does not get sorted into the proper place.

I will provide a plunkr if necessary but it may take a while to set up.

Is this known functionality / a bug?

[thgreasi]

That's expected since the ng-repeat re-renders after when the model collection changes and what seems like a "move" is actually a "remove this from here and render it there".

As a general practice on angular js apps, you should not expect the DOM to be there and remain intact. As a result it is suggested not to use it to hold any state.
eg: Lets say that under a condition a specific element should be colored differently. In this case, you should use a scope property to hold the state and use a css class along with ng-class to render the appropriate result.

[thgreasi]

Please also keep in mind that when using ui-sortable, it is suggested to not manipulate the direct children of the sortable element ("> *").

[Lorless]

Thanks for your reply.

I forgot to mention something for anyone who finds this. I was using angular-schema-form and they have hacked around ui-sortable so that it actually performs no manipulation of the DOM. It completely disables the re-rendering of sorted items and instead re-arranges the array model so values change and update but no HTML changes occur at all. This makes sense in the context of angular-schema-form since it wants to maintain control of rendering the form.

This looks like an unavoidable problem with angular-schema-form but i'm going to try to work around it somewhat by watching for model changes. Cheers.