Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support inserting list element at the top #3270

Closed
adrian5 opened this issue Feb 15, 2020 · 1 comment · Fixed by #4465
Closed

Support inserting list element at the top #3270

adrian5 opened this issue Feb 15, 2020 · 1 comment · Fixed by #4465

Comments

@adrian5
Copy link
Contributor

adrian5 commented Feb 15, 2020

Feature

It would be nice to have the option of inserting new items at the beginning of the list, instead of appending them at the end. This is vastly less efficient (the whole list has to be moved in the target document) but would greatly improve usability in some use cases.

Example: I have an image gallery constructed like so:

- label: "Images"
  name: "images"
  widget: "list"
  field:
    label: "Image"
    name: "image"
    widget: "object"
    fields:
      - {label: "File", name: "source", widget: "image"}
      - {label: "Caption", name: "caption", widget: "string" required: false}

If the user adds a new image, it appears at the bottom, so they have to scroll all the way down past the other images.

In my case, I would prefer to list to have newest-first order to begin with, as I cannot currently revert the direction of frontmatter data in my SSG (Hugo). If I wanted to manually maintain a newest-first order, I would have to scroll down, edit the new entry, and drag it all the way back up. Consider doing this each time in a list of 50 items – tedious!

Design consideration

There are two separate parts to this problem that can be solved independently.

1. Presentation: The UI could present the user with a reversed list that inserts items at the front, but keep the oldest-first order in the frontmatter. This might conflict with progressive loading, as the developers have discussed in other topics.

2. Storage: NetlifyCMS could allow the user to define the output (and hence input/read) format of the actual frontmatter. This potentially causes a lot more shifting of frontmatter in each operation, but certainly has strong use cases and doesn't clash with progressive loading (if implemented correctly).

Tangentially related: #54

@tomrutgers
Copy link
Contributor

Related to #1244

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants