Better handling of site settings with large amount of content (big lists)

Hi! I’m adding this topic to talk about improvements that might be made to how large lists are handled in settings.

Continuing the discussion from Discourse Version 2.1:

It seems like it boils down to three issues:

  • scroll-position-jumpiness on adding or removing list items makes it difficult to know what happened and stay oriented
  • long values are difficult to view
  • lack of feedback on saving makes it easy to click the reset button and lose content

It looks like a good solution to these problems was proposed here:

…which resolves everything except the issue of accidentally resetting the content by trying to click the “save” button multiple times; one solution to that problem might be to immediately replace the save button with a spinner after a click.

As far as I can tell this project isn’t already in the works, is that right? Does this strike everyone as the best solution?


Yes I will tackle this for 2.1, as said in the other post it’s definitely at the top of my list, I want to work on few things concerning the dashboard first and I will come to this then.


Ok, sounds great. Thank you!

I took the opportunity of your post to think more about it and give a more detailed answer to your question.

I do agree your solution could solve it. We would have to decide what is a good “grace period” for this spinner though. Something which would avoid fast click but don’t bother users, 1s ? I’m also a little bit concerned, that it would make the UI feels a little bit slow. So we would have to try it and see how it feels. Any other idea I have so far would involve to move the save button at another place, and this is not ideal as it would just make things slower for the critical path.

I would also want to add another new issue to this nice recap: very long urls. ATM if we have a very long URL it will either overflow the container and be hidden (making it impossible to click on the or we would have to display it on multiple rows, making it very ugly. The simplest solution I see here is to move the to the beginning. So I might make this change globally to any select-kit input. Another solution would be to make the text fade out and have the over at the end, but this would be quite complicated when the other solution is so easy. Do you have another idea on this?


Sorry Jay,

We would still be more than happy for you to build this provided you follow @joffreyjaffeux guidance as he built the original control and select kit library.

I think the best next step here would be some visual mockups, I think even hand drawn is fine if that is the way you roll :wink: then once we are comfortable with how the UI will look we can move ahead and do the code part.


Regarding the spinner, I think you’re right to worry about making it too slow – I’d think less than a second might be good, maybe even half a second? In addition to preventing accidental double-clicks, it can help give the user an indication that something was committed; currently it’s so fast that it if you were unsure of which button you clicked you might wonder if it was saved or dismissed. I’ll mock up a few variations and post them here to see if a spinner & very short delay makes you happy or sad.

Regarding the x vs. long urls, I can’t think of a better solution using this control than your idea to move the x to the beginning… I think that would work great. Ultimately maybe long lists of key-value pairs call for a purpose-built control, but I’m guessing that’s out of scope for this project? In any case I’ll follow @sam’s direction and put a couple of sketches together to see what you think.

Thanks again for your help.


I put together a mockup of what a spinner animation might look like:

The markup, scripts, and styles are rudimentary here and not meant to represent how it would be implemented, but I hope it gives a sense of the idea and it would let us play with the delay, etc.

This may or may not be what you’re after here – please don’t hesitate to let me know if you’ve got something altogether different in mind, and I’d be happy to try to sketch it out. In the meantime I’ll take a look at a draft of an option for what the field itself might look like with the changes you proposed.


I’m not sure we need to spend quite that much time on the animation here. (1) it’s an admin-only area, (2) you’re going to need a no-animation version for accessibility, (3) that’s a lot of moving parts.

How about simply disabling the reset button for ~2seconds after the confirm comes back from the server?

Also don’t forget what this topic is primarily about – improving the “list” data type. The reset button will help with every setting :slight_smile:


Fair points. I’ll mock up a simpler alternative for comparison.

1 Like

Here’s a version of what the list might look like with:

  • [x] at the beginning
  • key/value indicator in place of a comma
  • one item per row


or a gif if it’s helpful.

@joffreyjaffeux, you mentioned adding ellipses (shown in your screenshot); those aren’t included here but I’ll add them if you think it makes it more clear.

Does this (plus disabling the reset button) more or less give us what we’re after? I still think there would be some value to showing a spinner on clicking ‘save’; maybe simply replacing the checkmark with a cog, with no other animations, would be easy enough to implement without adding complexity.


This looks good, can you scroll sideways to to see the full text?

How doe the UI look for adding pairs?

Here’s one way side-scrolling could work:

Currently adding key/value pairs works the same as it does in the current list control (gif). If it’s not clear, I’m faking the arrows for these screenshots by adding them to the text before I paste it into the field.

The idea is that in practice you’d paste key,value|key,value just like before, except here we’d convert the delimiter to arrows after the paste. If it’s in the scope of this project I’d be happy to work on ideas for improving the way we add items to the list (or to work on your idea if you already have a plan).

This feels pretty high friction to me, especially the adding part, I wonder if simply extending this makes more sense:

This control feels way more natural as a way for dealing with these lists.


Aesthetically speaking, having the entire line be a button is not ideal, so I’d go with @sam’s idea.

Absolutely – that’s much nicer. I’ll take a look.

Another advantage to this over the whole line being a button is that text selection isn’t going to be an utter pain.


Note, Jay has unfortunately ran-out-of-time here, @joffreyjaffeux will be taking on this feature for 2.1.


I’m almost done on this:

On the screen you can see the two base “list” types available (in core and plugins): list and compact_list

Will add more test and should probably be able to PR this tomorrow.


@sam should I keep the drag/drop behavior? If no, should I have a way to reorder it?

I would not worry about order here for now. In general when you have long lists like this order does not matter. We can deal with this later.