This package is awesome!! №2

[interk0t]

I really liked your library.
It includes the key functionality that should be for a sorting list. Many similar libraries either do not support Svelte or do not have the necessary functionality for such a library. The key aspects that are positive for this library that can be highlighted:
Functionality:

• Horizontal / vertical list
• Element lock
• Element handle
• Lock on a specific axis (very important)
• Boundaries (very important)
  Visual:
• Smooth animations for the ghost of the element
• No jerks when taking an element and when releasing it (very important) this interaction with elements becomes very pleasant (not available in many libraries)
  Ease of use:
• The library provides a minimum of elements for creating a list (, ). This corresponds to the trends and style of Svelte itself

What I would like to see in the next versions of this library, and what functionality is missing (my opinion):

• First of all, as @elron said, support multiple droppables
  (this will greatly expand the capabilities of the library, which with the existing ones will make it a cut above the rest)
• SortableList.enable() for connection and SortableList.disable() - very convenient methods that allow you to disable all functionality in those components of the project in which it is not needed at the moment (we are talking about a fairly global project with a large number of nested components and their functionality)
• a very important functionality that allows you to move an element while scrolling the list of elements, this function is extremely necessary

Methods:

• SortableList.onInit(()=> {}) the event would be triggered whether SortableList should be initialised automatically when you create an instance
• SortableList.onDragStart(()=> {}) during the start of dragging
• SortableList.onDrag(()=> {}) during dragging
• SortableList.onDrop(()=> {}) when element was dropped
• an event that would signal that the element's movement has reached the Boundaries of another container with elements (if multiple droppables are implemented)

Props:

• isSortable . At the moment, the library allows you to use two props that block interaction using isLocked and isDisabled, but none of these props can "freeze" a certain element so that its position in the list will not change (it will not be sortable)
• isSortableBetweenZones is an option to specify whether a given element can be moved to any other zone (if multiple droppables are implemented)

Issues:
I tried to create 1000 sortable elements and with such a number, the fps in the browser significantly decreased and it became difficult to move the element, since the animations lagged, is it possible to make some optimizations in this regard. I understand that the scenario in which the user will have 1000 elements is unlikely, and even if the developer does not use virtualization, but if there is an opportunity to optimize, it would be great.

I want to say that in my opinion, having tried almost all the libraries dedicated to sorting lists, this library solves many problems and it has a huge potential to become the best among the rest, this will be a good contribution to the Svelte community!

[rodrigodagostino]

Hi, @interk0t! :) Thank you very much for reaching out, and thank you for taking the time to provide all that feedback.

First of all, I gotta tell you I’m very glad you noticed the smooth animations and element interactions. I put a considerable amount of effort to have them work the way they do, specially in mobile devices, and I’m very pleased to know this can also be perceived by other people :)

You also laid down a very interesting roadmap for me, so let’s go point by point:

Support for multiple lists/droppables

These past few days I’ve been trying out a few different possibilities that came to mind, and for the moment it seems only two of them might be possible:

• Add a mandatory new component (<SortableContext>) to serve as context for multiple lists.
• Add the necessary logic to <SortableContext> and <SortableList> in order to allow <SortableList> to work without <SortableContext> if only a single list is being used.

To be honest, I don’t even know if the second option will actually be fully plausible. What do you think? Would it be a good trade-off to add a mandatory new component into the mix in order to support multiple lists? @elron feel free to chime in too :) The more I think about it, the more I see no way out of having a mandatory <SortableContext>.

SortableList.enable() and SortableList.disable() methods

How could a feature like that be added considering the architecture of Svelte components? Is there an example that you could provide? I’m very interested in this feature.

Support scrolling while dragging

To be honest, I don’t even know what is necessary for this to be possible, but I will look into it, it sounds like a good addition ;)

Events

It should be fairly simple to add events like on:init, on:dragstart, and on:drop. I will also look into it. I was thinking that I could even replace the current on:sort and on:remove for something more broad like the list you suggested.

Props

isSortable and isSortableBetweenZones sound like good additions, so that’s also something I will try to implement.

Virtual lists

At some point I considered virtualizing the lists when needed, but it felt like something that wasn’t really necessary for this little package. I mean, I was thinking that most people making use of it won’t be creating lists of 500 items or more. Accessibility is one of my priorities here, and virtual lists are not that friendly when it comes to a11y. But I would like to at least provide the support needed for developers who want to use virtual lists. I’m not sure what would be needed from my side to lay the grounds for that, but I will look into it :)

Optimization

I usually try to optimize as much as I can of the code I write. That doesn’t mean that there are no improvements left to be done, but I’ve definitely covered as much as my knowledge in programming allowed me to :P

I gotta thank you again, honestly! Your feedback was very inspiring and has fueled my hunger for this package even more. It’s clear to see that you have considerable experience in this matter, and I’m grateful for the time you spent setting some guidelines for me. I will make good use of them :)

[elron]

SortableContext

Having <SortableContext> as a mandatory is fine as long as it works :) It's not a big deal.

But if you want even cleaner, maybe you can create a new svelte component: <SingleSortableList> that actually invokes both <SortableContext><SortableList /></SortableContext>.

but anyway, I wouldn't mind adding <SortableContext> even for single list.

Support scrolling while dragging

I agree that support scrolling while dragging is very important, as I have a very large item set (500~ items that go in about 20-30 different lists).

I know it sounds a lot but actually this is how big my lists are. (I use react-beautiful-dnd to sort course content and lessons, so each list is a chapter and each lesson is an item).

[interk0t]

From a compactness point of view, it would be good not to use context in cases where there is only one list, it would be super convenient.

SortableList.enable() and SortableList.disable() methods

To be honest, I have no experience writing libraries, but usually such methods are added to libraries that provide functionality at the class level, I don’t know how your library works, but maybe it was possible to pass this value as a prop, and going so that this method/prop completely disables the library functionality on a specific element (removing style classes, etc.)

Support scrolling while dragging

A very useful thing, and it is very necessary when the list of elements is larger than the height or width of the screen

Virtual lists
It would also be very useful, but this is the last one, as it seems to me

Well, how can I say, I have little experience in programming, but I really needed such a library for svelte, and none of the existing ones met the requirements, although the requirements were quite logical and necessary for such a package, your library ALREADY solves most of the problems, and in my opinion the best option of all existing ones, and if its improve, partially or completely based on my suggestions, that would be great

[elron]

Inspired by @interk0t last message:

From a compactness point of view, it would be good not to use context in cases where there is only one list, it would be super convenient.

Just throwing an idea for a better name than <SortableContext>, if we want it to support single lists without content wrapped:

<SortableList> - main (can work stand alone - all event dispatchers goes here)
<SortableSublist> (inside SortableList, but not mandatory)

I imagine that you can have unlimited nested sublists (<SortableSublist> inside <SortableSublist>)

If we need to specify If there are nested or not,
Perhaps we can do it with a prop:

<SortableList single> or <SortableList hasSublists>

That way inside the wrapper component we can do:

{#if hasSublists}
    <slot />
{:else}
    <SortableSublist>
{/if}

[mmilo]

Support scrolling while dragging
To be honest, I don’t even know what is necessary for this to be possible, but I will look into it, it sounds like a good addition ;)

@rodrigodagostino, I noticed that dndkit has a vanilla JS version that is a little hard to find but here is how they handle their scrolling capability which might be source of inspiration - https://github.com/clauderic/dnd-kit/tree/experimental/packages/dom/src/core/plugins/scrolling + https://github.com/clauderic/dnd-kit/tree/experimental/packages/dom/src/utilities/scroll

Their autscroll handling is particularly good as it handles the case of scrolling within a parent container and also scrolling the window if the parent exceeds its bounds.

[rodrigodagostino]

Thank you for the suggestion, @mmilo@! I will take a look :)

It’s like you read my mind because I’ve been working on the autoscroll feature this past few days, and I’m pretty sure I will be delivering that before the multiple lists feature, just in case someone using the package doesn’t want to migrate to the following version.

Thank you again for your help and support :)

[interk0t]

hello @rodrigodagostino !!!
During this time you have updated the library well, and added many useful things, I would like to know if support for moving elements between lists will be added? Will the ability to create nested lists (a list in a list where you can move not only lists in lists, but also lists in lists and elements between these lists) be added?

[rodrigodagostino]

Hey, @interk0t! It’s nice to see you around here again :)

Nested and multiple lists are definitely in my bucket list. I started working on multiple lists a while ago, but it ended up being quite a lot of work, so I decided to (mostly thanks to Elron’s suggestion) continue working on it after the migration to Svelte 5 is complete. I haven’t done much around nested lists, but hopefully it will be possible to add that feature into the project too :)

The next steps will be:

• Pushing the wrapping support a little bit further (this is almost done).
• Adding transitions customization.
• Optimizing the performance a little bit more.
• Launching v1, which will stick to Svelte 4.
• And then launching v2, which will move onto Svelte 5.

After that is complete, I will probably start working again on multiple lists. I’m trying not to rush too much just so I don’t include changes that I might regret later.

Are you requiring any of those 2 features you mentioned for something you’re working on?

[interk0t]

It's great that you have long plans, the transition to svelte 5 and the ability to distribute over lists. Yes, I had a need for a shareholder nested lists and moving between them elements, when I realized that I can not implement this by standard library tools, to start thinking about what trick can be done to make it work, and so far I have not found, savings as for nested lists too. I also needed to implement a "tree", a list with files and folders, where you can move files to folders and folders to folders, in the end it turned out to be implemented only by making changes to the library itself.

when I realized that nested list doesn't work like that...

<SortableList.Root on:dragend={handleDragEnd}>
        <SortableList.Item >
                <SortableList.Root on:dragend={handleDragEnd}>
              		<SortableList.Item >
              		</SortableList.Item>
                </SortableList.Root>
        </SortableList.Item>
</SortableList.Root>

I changed the data structure from which the markup was output from nested to flat, in each output object I set the depth, so you can manage the styles at what level the folder or file is located, so this is what happened

[rodrigodagostino]

@interk0t did you create that interface using SSL? That was pretty clever, and looks really cool :)

But if I’m also getting this correctly, items simply look as if they were nested (through the depth prop you mentioned), but the data doesn’t really tell to which parent an item belongs to. Is that correct?

This is a really, really interesting use case :)