Re:Trello clone with Phoenix and React – 5-part tutorial
by thedufer on Saturday January 23, 2016 @10:47AM
(#10958695)
Like I said, Trello re-numbers when things get to close together, so you never see something like that. Obviously there are trade-offs, but very occasional re-numbering vs. a ton more complexity seems like an easy decision.
"you'd need a library" is not a solution when you have API consumers in dozens of languages.
Re:Trello clone with Phoenix and React – 5-part tutorial
by strmpnk on Saturday January 23, 2016 @11:34AM
(#10958867)
If you can sort fractions and call a function to get something between two points, then that's the entirety of the complexity. The "library" is about a hundred lines in JS and less in Erlang. The logic, which I have written in the past to do conditional reindexing has a worse interface and ends up with about the same LOC burden.
Seriously, I've done both of these and the complexity is about the same. One route just ends up with a much better separation of concerns where the other has surprising edge cases which I see hit far more often than I would have imagined.
Re:Trello clone with Phoenix and React – 5-part tutorial
by thedufer on Saturday January 23, 2016 @12:57PM
(#10959206)
The complexity sounds fairly similar, but my point is that there's a world of difference between server-side complexity (implement once) and client side (implement 3 dozen or so times).
Re:Trello clone with Phoenix and React – 5-part tutorial
by strmpnk on Monday January 25, 2016 @09:08PM
(#10971456)
Fair enough. Getting a usable API that works reliably here is tricky though. I've often fallen back to a sort of indirection like "move this card right after that one" ... this only works if you can calculate that right away since that card can be moved by some other agent.
The above might seem odd but is much more reliable than midpoints and not hard to implement. The representation of the index can use multiple formats, one of the easiest is just a pair of numbers in a fraction.
The problem with floating point numbers is that you'lol lose precision faster than you might expect. See my gist for an example of 40 fractions from a production database where there is no double precision floating point number between them.