Sean Washington

Yeah, I thought about that too, or grabbing before and behind. The gem is pretty quicky but it'll do in a pinch! Thanks for all the help!

Alright, so I think I'm good here! I was pretty close to having it done manually, but acts_as_list got me the rest of the way there. Now, on dragend I'm getting the current index of the item in the list, and sending an update request for that product only. From there acts_as_list is taking care of updating the rest for me. This could work with infinite scrolling, and I think that whenever the user is filtering the product list, I'll just disable those drag/drop buttons until I figure out a way to extract the actual index within the scope of the whole list.

@jacob, yeah, that's exactly what I'm thinking! I believe that acts_as_list might make this a lot easier since I can deal with only the dragged item and let aal deal with the complicated logic for now. There's just not enough hours in the day!

Thanks for the replies @chris, @jacob!

I've thought about having just a subset of orderable items as well @jacob. Another fun fact is that products can belong to stores, sales, and collections (think like a pinterest board), and they all have a unique sort index through their join tables (store_product.sort_index)! That's all working great so far.

By not scalable I mean that I don't want to render all 100, 200, 500, products that a store might have so that they can drag and drop to reorder things. A subset like featured products might work, but I'd have to sell that to the store owners and to my boss.

Also, I haven't even thought about dragging a product across pages.. I'll check out acts_as_list gem and think about it a bit!

Hey there!

I've got a collection of models (Product) and each product has an attribute called sort_index that allows the store owner to set a specific order for their products. The UI allows them to drag/drop them around to set the order. Because of that, I need to update the index of all of the products. Is there a better way to handle this? This solution obviously doesn't scale well. Also, when thinking about throwing pagination to the mix, it falls apart because then we can't rely on the index of each product in the list (item 1 on page 2 should not have a sort index of 0 for example)

Here's a gif of the UI: https://cl.ly/jpad

With that in mind, how might you all implement the API side of things?

Hey Chris!

I actually have both of those routes for observations setup, but the nested resouce I'm only allowing index and show. I think accepts nested attrs makes a lot of sense here and would be very convenient to my future self. Thanks for the reply!

Hey all!

I'm just curious, how would you surface the ability to create nested items in an API? Say you have a model Post that has_many observations.

I have my base routes for both Post and Observations, but in thinking about a client using the API, they'd probably need the UI to have the post form and observation forms in the same view since observations are directly tied to posts. One problem is that when you're adding a post, it's new so we can't just create an observation by sending a POST to /api/v1/observations because we don't have a post_id to assign to yet. I suppose someone making the client (my future self) could force the creation of a post before adding observations to it, but that feels more like a limitation than anything.