Persistent reordering of collection in Meteor not working

[macsj200]

When I reorder my lists in meteor, the order fields are all set to the same value after dragging-and-dropping the elements. The orders start out distinct, but after playing with the ordering on the client all of the order attributes are set to the same values.

This may be related to issue #287 or #197.

Original ordering:

After scrambling elements in UI:

Also, I'm getting this error in the meteor console when I reorder:

I20150523-12:53:38.081(-6)? Exception while invoking method 'rubaxa:sortable/collection-update' Error: Match error: Expected string, got object in field [0]
I20150523-12:53:38.081(-6)?     at checkSubtree (packages/check/match.js:159:1)
I20150523-12:53:38.081(-6)?     at packages/check/match.js:206:1
I20150523-12:53:38.081(-6)?     at Array.forEach (native)
I20150523-12:53:38.081(-6)?     at Function._.each._.forEach (packages/underscore/underscore.js:105:1)
I20150523-12:53:38.082(-6)?     at checkSubtree (packages/check/match.js:204:1)
I20150523-12:53:38.082(-6)?     at check (packages/check/match.js:32:1)
I20150523-12:53:38.082(-6)?     at [object Object].Meteor.methods.rubaxa:sortable/collection-update (packages/rubaxa:sortable/meteor/methods.js:13:1)
I20150523-12:53:38.082(-6)?     at maybeAuditArgumentChecks (packages/ddp/livedata_server.js:1617:1)
I20150523-12:53:38.082(-6)?     at packages/ddp/livedata_server.js:648:1
I20150523-12:53:38.082(-6)?     at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1)
I20150523-12:53:38.083(-6)? Sanitized and reported to the client as: Match failed [400]
I20150523-12:53:38.083(-6)? 

Any help with this would be greatly appreciated.

[dcworldwide]

👍

[FickleLife]

I also get all items ending up with the same "order" value after sorting multiple times in the UI - any ideas?

[FickleLife]

Just wondering if any ideas on how to solve this? Thanks

[jhawver]

Same problem here. I get the following error in the console:

update failed: Access denied

[chiester]

I have the same issue. All fields end up with the maximum value, as seen above. In my case, there are four documents that are being sorted and after the sort the order property is set to 4 in all of the documents.

[day]

Like several others, my order values, which I manually initialized to be unique, eventually gravitate toward a single value. However, I'm not seeing an error in the Meteor console. Is anyone willing to tell me how I could work on the solution myself? I'm considering forking and publishing my own version to Atmosphere just so I can play with it...hidden w/ set-unmigrated of course. What's the standard protocol here? I'd be glad to help solve this.

EDIT 1: I looked into using a local version so I could play around and debug, but Meteor doesn't seem to be honoring the PACKAGE_DIRS env var. Not an issue for this thread obviously...but PM me if you have advice. Thanks!

EDIT 2: Just answering my own question here. My problem was that I was treating this repo, which (obviously) has multiple integrations in it (Angular, React, etc.) as if it was simply a Meteor package. In fact the Meteor package is only one subdirectory within the repo. There was a dependency on ../Sortable.js (which I moved into ./main.js). But then yes, everything worked just fine and I'm off!*

* The point being that I can now try to debug this sort order weirdness. ;-) Cheers!

[jishaal]

@day, did you have any luck?

[day]

@jishaal: Yes. My experience was that with the sortable elements displayed in ascending order, the problem was intermittent and difficult (though not impossible) to reproduce; I could not formulate a reliable method for reproducing the problem. However, with the sortable elements displayed in descending order, the problem was consistent and could easily be reproduced. A reading of the code in the adjustOrders function revealed an underlying assumption that the order of elements in the DOM was in the same direction as the sort order (i.e. ascending order was assumed). The comments showed that elements were conceived of as moving "up" or "down" in the sort and the intervening elements were slated to have their order field incremented or decremented accordingly. All I did is reverse the order of the arguments in the event that elements were displayed in descending order. After I made that change, I could no longer reproduce the problem with either ascending or descending elements. I have not been able to wrap my head around why it may have effected the ascending case, since the code does exactly what it always did in that case...but that's my experience anyway. The problem is solved for me. Here's my commit; I've not yet made a PR: day@cc483ad

[day]

@chiester & @FickleLife Any chance you guys were displaying your set in descending order?

[jishaal]

@day, thanks for the info! Much appreciated.

[ryparty]

@day you just saved me many many more hours, thanks!