Eleventy: Standard data model for individual templates, items in a collection, pages in pagination

[zachleat]

Per @paulrobertlloyd documentation:

Individual Template | Collection Item or Pagination Item
-- | --
page.url | item.url should be item.page.url
page.date | item.date should be item.page.date
page.inputPath | item.inputPath should be item.page.inputPath
page.outputPath | item.outputPath should be item.page.outputPath
page.fileSlug | item.fileSlug should be item.page.fileSlug
content or layoutContent (only available in layouts) | item.templateContent should be item.content
title | item.data.title should be item.title
foobar | item.data.foobar should be item.foobar

https://www.11ty.io/docs/collections/#individual-collection-items-(useful-for-sort-callbacks)

[zachleat]

This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open.

The enhancement backlog can be found here: https://github.com/11ty/eleventy/issues?utf8=%E2%9C%93&q=label%3Aneeds-votes+sort%3Areactions-%2B1-desc+

Don’t forget to upvote the top comment with 👍!

[zellwk]

I remember I had an error where I could only get page date with `page.data.date. Can't remember how to reproduce this error, but I thought you should know. Didn't file an issue then. Will update again if I encounter the error.

Otherwise, everything else looks good! :D

[edwardhorsford]

Per #280, I'd really like if paginated pages exposed the key of the thing currently being iterated.

[zachleat]

Per https://mobile.twitter.com/zachleat/status/1148228091703152640 it might be nice to also expose the inputContent of the template in both page and collection items.

I believe this _might_ be already on the issue somewhere but was unable to track it down in a search. If someone finds it please link it up!

[Ryuno-Ki]

inputContent is only mentioned in #13 and #179 beside here.

[edwardhorsford]

It's been a while since I looked at it, but I think inputContent would have made my rss feed much easier (not built yet because the rendered html was harder to work with)

[Munter]

I just want to mention I had a very hard time finding this information since it isn't really clear from the docs that custom data properties are exposed in the global scope of the individual template.

My troubles were further increased by not being able to json stringify many of the data structures inside the template because of circular references. Otherwise I normally just use <pre>{{ page || json }}</pre> to see what's available to me. However, this failed completely when trying with page.data. There is also no good way to have liquid json stringify its outer scope.

So essentially, as a first time user, I had to do a LOT of guessing and googling until I finally found this page

[paulrobertlloyd]

I have an additional use case for having a consistent/predictable data model for page frontmatter data.

---

I’m trying to create pages from data. I have a global data file that contains an array of data, then formats this in way that reflects the page data model used internally by 11ty:

const slugify = require('@sindresorhus/slugify');

module.exports = function () {
  const things = [{
    title: 'Foo',
    summary: 'Bar.'
  }, {
    title: 'Baz',
    summary: 'Qux.'
  }];

  return things.map(thing => {
    const fileSlug = slugify(thing.title);

    return {
      date: new Date(),
      fileSlug,
      url: `/things/${fileSlug}`,
      data: {
        layout: 'thing',
        title: thing.title,
        summary: thing.summary
      }
    };
  });
};

This provides following data object for each item:

{
  date: '2020-03-23T09:17:41.270+0000',
  fileSlug: 'foo',
  url: '/things/foo',
  data: {
    layout: 'thing',
    title: 'Foo',
    summary: 'Bar'
  }
}

I can create pages by paginating over this data, and give each item in the pagination array the alias page:

---
layout: thing
title: Thing
pagination:
  data: things
  size: 1
  alias: page
permalink: "projects/things/{{ page.fileSlug }}.html"
---

This means in my templates I can call the following variables:

{{ page.data.title }}
{{ page.data.summary }}

However, for pages not created this way, I need to use the following variables:

{{ title }}
{{ summary }}

Might it be an idea to maintain the shorter variables for frontmatter data (e.g. {{ foo }}, but as aliases to the ‘true’ variable name (e.g. {{ page.data.foo }}).

This would also maintain consistency with how you loop over collection items; you can’t use {{ foo }} but have to use {{ item.data.foo }}.

Does this make any sense?

[paulrobertlloyd]

@zachleat I think this issue is closely related to computed data, at least from my experience. Much of my use of computed data is an attempt to expose a predictable and consistent API for templates; were that already the case, my use of this new feature would be solely for _computing_ data, not _reassigning_ values.

I say this having now found myself with a variable in my templates called item.data.venue.data.venue.title 😅 That said, I’ve arrived at this point because I’m addressing data from a collection (called venue) created by pagination (with the alias venue) which uses data from global data, so maybe this is an accurate reflection! 🤪

[paulrobertlloyd]

Really hoping to see this breaking change make an appearance in upcoming betas for v1.0 😉