Pagination size: 1 doesn't populate page arrays but returns single items

[SirePi]

Describe the bug Setting size 1 in a pagination results in having a flat array instead of an array of arrays, as described in

To Reproduce Use the following njk

---
pagination:
  data: testdata
  size: 1
  alias: posts
testdata:
  - itemkey1
  - itemkey2
  - itemkey3
---
{% for item in posts %}
{{ item }}<br>
{% endfor %}
<hr>
{{ pagination.pages | length }} pages

Change size to a value greater than 1 to have the correct behavior

Expected behavior I expected to see one item and 3 pages with size 1, but apparently it returns "itemkey1" directly, without wrapping it in an array, with the result of having each character treated as a single item instead.

Screenshots OK (size 2)

NOT OK (size 1)

Expected (size 1)

Environment:

• OS and Version: Windows 10 64 bit
• Eleventy Version 0.11.0

[onion2k]

I can replicate this bug.

A temporary workaround is to wrap the items in square brackets to turn them in to array literals;

testdata:
  - [itemkey1]
  - [itemkey2]
  - [itemkey3]

[SirePi]

Thanks, but unfortunately what I posted is just a POC, I'd like to have it work in a collection-based pagination 😄

[svivian]

I just noticed this myself. It is explained in the docs:

When size is set to 2, pagination.pages will look like: [['item1', 'item2'], ['item3', 'item4'], ['item5', 'item6']]

When size is set to 1, pagination.pages will be the same as the original data: ['item1', 'item2', 'item3', 'item4', 'item5', 'item6']

But to me this is just wrong. The same code should work whether the size is 1 or 2+.

[Snapstromegon]

I agree with @svivian, @onion2k and @SirePi that I would consider this a bug.

Option 1

Maybe an option to resolve this (because I see the good intention of leaving out the array for e.g. CMS provided data where you always use pagination 1) would be to insert a magic keyword that leaves out the array. Especially now that eleventy serverless is coming in, it would be totally possible to leave page size to a query parameter so you don't even know beforehand if it's 1 or more.

So my proposal would be either:

---
pagination:
  data: testdata
  size: 1
  alias: posts
testdata:
  - itemkey1
  - itemkey2
  - itemkey3
---

would result in [["itemkey1"], ["itemkey2"], ["itemkey3"]], while

---
pagination:
  data: testdata
  size: some_magic_string_which_might_be_unwrapped
  alias: posts
testdata:
  - itemkey1
  - itemkey2
  - itemkey3
---

would result in ["itemkey1", "itemkey2", "itemkey3"].

Option 2

Another option would be to add a format key to the pagination data, so a user could specify the format tje data should be presented as in the pagination items. Possible values for this key might be:

• default -> current bahavior to keep backwards compatibility or the array behavior
• array -> current behavior, but pagesize 1 items are also array wrapped
• object -> for object data, so instead of a key array we could get an object with keys and values
• objectArray -> like object, but it's an array of objects with a single key (the current one)
• single -> has to have pagesize 1 and doesn't wrap items in arrays (like currently with pagesize 1)
• singleObjects -> same as single, but with object behavior

This option might increase the implementation difficulty and the cognitive load for new users, but it would offer the benefit of making working with dictionary data even easier for experienced users.

Of course naming is always up for debate.

Maybe instead of using a format string, it would be useful to use "format modifiers" as a list, so you wouldn't write

---
pagination:
  data: testdata
  size: some_magic_string_which_might_be_unwrapped
  alias: posts
  format: objectArray
testdata:
  - itemkey1
  - itemkey2
  - itemkey3
---

but you would write

---
pagination:
  data: testdata
  size: some_magic_string_which_might_be_unwrapped
  alias: posts
  format: 
    - object
    - array
testdata:
  - itemkey1
  - itemkey2
  - itemkey3
---

But this is probably too hard to document and maintain and keep in mind which format modifiers are compatible.

I know this became a long comment, but I hope it becomes a startingpoint for a good debate.

[Snapstromegon]

Hey @zachleat, I just want to push this bug (since it's one of the oldest open ones and v3 seems to be coming up). What do you think about my comment above? I personally would go with option 1 and would be willing to at least try creating a PR, if you could decide on a magic value.

[zachleat]

Ah—hmm. I don’t consider this to be a bug. It’s strictly limited to the use of alias and I consider it to be sugar around that feature. Let me re-evaluate my bias though.