ui.itemProps on collections

[newash]

Hello!

I created this PR for #3389

I tried it with experimental-examples/tina-cloud-starter adding the draft field and the ui.itemProps to the collection schema:

...
const schema = defineSchema({
  collections: [
    {
      label: "Blog Posts",
      name: "posts",
      path: "content/posts",
      format: "mdx",
      ui: {
        router: ({ document, collection }) => {
          return `/${collection.name}/${document._sys.filename}`;
        },
        itemProps: (item) => ({
          label: item.draft ? `🚧 ${item.title}` : item.title,
          className: item.draft ? 'bg-blue-50' : ''
        })
      },
      fields: [
        {
          type: "boolean",
          name: "draft",
          label: "Draft",
        },
...

and could produce this:

---

I'm not sure though if both packages/@tinacms/schema-tools/src/types.ts and packages/@tinacms/schema-tools/src/types/SchemaTypes.ts file needed to be updated, or one would have been enough.

I also haven't looked into your tests, so I'm not sure about the necessary tests either.

[changeset-bot]

🦋 Changeset detected

Latest commit: 08c26ac

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 13 packages

Name	Type
@tinacms/schema-tools	Minor
tinacms	Minor
@tinacms/cli	Patch
@tinacms/graphql	Patch
@tinacms/mdx	Patch
starter-basic-iframe	Patch
starter-basic	Patch
starter-empty	Patch
e2e-next	Patch
kitchen-sink-starter	Patch
@tinacms/starter-iframe	Patch
@tinacms/starter	Patch
kitchen-sink	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[CLAassistant]

All committers have signed the CLA.

[github-actions]

	Warnings
⚠️	packages/tinacms was modified but its README.md was not updated. Please check if any changes should be reflected in the documentation.
⚠️	packages/@tinacms/schema-tools was modified but its README.md was not updated. Please check if any changes should be reflected in the documentation.

Modified Packages

The following packages were modified by this pull request:

• @tinacms/schema-tools
• tinacms

Generated by 🚫 dangerJS against 08c26ac

[newash]

While the PR is nicely small, you might agree that it's not very bandwidth-efficient.

What I could change here, is to introduce a _sys.fields attribute
in packages/@tinacms/graphql/src/resolver/index.ts instead:
an object that would have only the subset of fields.

The question is: what that subset should contain?

• everything but the one with isBody: true ?
• everything but those with type: "rich-text"?
• only those with simple types? (not rich-text and not object)

That is a design decision, and you probably in a better position than me to answer that.

[jeffsee55]

Yeah this is a good point, it has the potential to de-optimize that query, it might be best to provide a property on field definitions that would populate it to the _sys.fields property, as you noted.

It's not so much a matter of the size of payload, but also if we can avoid providing the _values then we can skip retrieving the document entirely (basically the same thing we do with _sys.title, except it'd be a JSON type probably.

[jamespohalloran]

Just thinking ahead a bit, If the user can specify which fields they want available to that list-view, maybe we should allow them to create new columns for a given field?
In that case, instead of using itemProps to control the label field, they'd be able to control the UI for any given column, as opposed to just the title-label.

(Another common example might be including a custom "author" field in this list).

[jeffsee55]

Thanks for the PR @newash - we'll discuss the ramifications of including the _values key as you mention, but this is a solid approach!

[newash]

Do you have any updates on this @jeffsee55 ?

[jeffsee55]

We'll be discussing this next week and we'll get back to you, thanks @newash !

[newash]

Any update lads?

[jeffsee55]

Hey @newash - sorry for the delay, this PR is definitely something we'd like to have but it introduces more complexity than we'd thought. We don't have the bandwidth right now to approach it properly, but do plan to address it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[newash]

I still need this

[jeffsee55]

not stale

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[newash]

still need this

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[newash]

will this ever be addressed?

[scottgallant]

Hey @newash, I've been thinking a lot about the suggestion here and would like to go that route:

#3411 (comment)

What do you think?

Our roadmap is fully booked for the next few weeks, but I'll try to slot this in shortly after that.

[newash]

Of course, I'm not going to argue against your obviously neater solution. 🙂