How to add dynamic (computed) fields on read?

[hdodov]

I have a posts collection and a categories collection. Posts have categories, but categories can have subcategories (which are other categories). Something like this:

const BlogPosts = {
	slug: "blog-posts",
	fields: [
		{
			name: "category",
			type: "relationship",
			relationTo: "blog-categories",
		},
	],
};

const BlogCategories = {
	slug: "blog-categories",
	fields: [
		{
			name: "subcategories",
			type: "relationship",
			relationTo: "blog-categories",
			hasMany: true,
		},
	],
};

Whenever a blog post is read, I want to also add the parent category of the post's selected category (if such exists). What would be the proper way to do that?

It seems to work with an after-read hook:

const addParentCategory = async ({ doc }) => {
	const category = doc.category;

	if (category) {
		const parent = await payload.find({
			collection: "blog-categories",
			depth: 0,
			where: {
				subcategories: {
					in: category.id,
				},
			},
		});

		doc.parentCategory = parent.docs?.[0];
	}

	return doc;
};

export const BlogPosts = {
	slug: "blog-posts",
	fields: [
		{
			name: "category",
			type: "relationship",
			relationTo: "blog-categories",
			admin: {
				position: "sidebar",
			},
		},
	],
	hooks: {
		afterRead: [addParentCategory],
	},
};

However, this results in two queries - one for the post and then one specifically for the parent category.

Is it possible to have Payload send a single query? I know that's possible in MongoDB with aggregation operations.

[hdodov]

@jmikrut could you help out? In addition to what I wrote in my initial comment, I also want to add a readTime field to the returned data from the API. Since it's computed and is not an actual field in the admin - what would be the best way to add it?

[jmikrut]

Hey @hdodov — sure thing. Here's a few answers for ya.

First up, no matter what you do, be it aggregation or anything else, Mongo will need to query the collections separately. You could reduce the latency by using an aggregate, for sure, because that way it's only 1 trip to the DB (which then queries on both collections), but I'd actually take a step back and suggest a better alternative in the first place.

Have you seen our nested-docs plugin?

https://github.com/payloadcms/plugin-nested-docs

It's pretty much exactly suited to this. You can see it in use on our website in a bit different context. In our website, we have pages that can have parent pages, which can have parent pages, etc. And we need to maintain a full list of "breadcrumbs" that allow us to output the full URL of the page based on the slug of each parent page.

Within that plugin, we do not make separate queries. Instead, we just manage a fewafterChange hooks that literally go resave each child doc when a parent doc is saved. So the parent doc info is actually saved on the doc. We also inject a breadcrumbs field that intentionally contains all the info we need per doc, so that we explicitly can avoid having to query for more docs each time a document is read.

See what I mean?

Now for your second question - readTime - this is what we would call a virtual field. One that does not store a value, but is calculated on the document.

@JessChowdhury just released a quick video on this exact topic here:
https://twitter.com/payloadcms/status/1645759920761962496

And there's a blog post here:
https://payloadcms.com/blog/learn-how-virtual-fields-can-help-solve-common-cms-challenges

Those should get you going. What do you think?

[hdodov]

Thanks for the detailed answer!

I tried the nested docs plugin, but I don't think it would fit my use case very well. It's capable of establishing parent/child relationships between documents in the same collection. In my case, I want to have a post with a category, and both of them reside in separate collections. In other words, I don't have posts that are parents or children of other posts.

For the time being, I think I'll stick to my current approach, because it's quick, easy, and flexible. If performance becomes an issue, I'll think about adding after-change hooks and embedding the data, similar to what you do in the plugin.

---

The readTime fields appears to make perfect sense as a virtual field, so I'll give that a shot.

[taismassaro]

hey @hdodov, I found this discussion while looking for a way to show a readonly "field" of another collection that has a relationship field to the one I'm editing. your code seems to work for finding the entity, but I can't seem to figure out how to make the UI actually update with the value.

basically I have an Exams collection that has a relationship field for Questions and then I wanna show which exam is related to each question.

hooks: {
    afterRead: [
      async ({ doc }) => {
        console.log({ doc });
        const exam = doc.exam;
        console.log({ exam });

        if (!exam) {
          console.log("no exam");

          const relatedExam = await payload.find({
            collection: "exams",
            depth: 0,
            where: {
              questions: {
                in: doc.id,
              },
            },
          });

          console.log({ relatedExam });
          doc.exam = relatedExam.docs?.[0];
        }

        return doc;
      },
    ],

am I missing something to update the UI or should this be done in some other way? 🤔

[hdodov]

Could you explain what you mean by "make the UI actually update with the value"? Perhaps a screen recording would be most illustrative.

[taismassaro]

thanks for your reply! here's the screen recording, I hope it makes sense. I have the hook from my previous message in the Question collection and I wanted the Exam field to be automatically populated based on which exams have that question assigned to them.

Screen.Recording.2023-08-30.at.10.05.17.mov

[hdodov]

I think you have to only return the related document's ID, if I'm not mistaken. I think I had a similar issue and resolved it by not including the entire doc and only its ID instead. Something like this:

const afterReadQuestion = async ({ doc }) => {
	const relatedExam = await payload.find({
		collection: "exams",
		depth: 0,
		where: {
			questions: {
				in: doc.id,
			},
		},
	});

	// like this:
	doc.exam = relatedExam.docs[0]?.id;

	// or like this:
	doc.exam = {
		id: relatedExam.docs[0]?.id,
	};

	return doc;
};

I guess it depends on what type of field you have for doc.exam. If you have a select with multiple options, you might need to have it as an array, e.g.:

doc.exam = [relatedExam.docs[0]?.id];

Here's what I would do:

1. Remove the afterRead hook
2. Manually put a value in the "Exam" field
3. Log the value of the field when it gets loaded on the page
4. Check what value is stored for the field in the database
5. Readd the afterRead hook and try to dynamically assign doc.exam with a similar value to the ones in step 3 and 4 and see what works

Does that make sense?

[taismassaro]

ha, the id did the trick! I'm still getting familiar with how things work in Payload. 😬
thank you so much for taking the time to help, @hdodov!

[hdodov]

@taismassaro well, I'm not that familiar either. I just have the Payload source code cloned on my machine and whenever something doesn't work - I look at it. It's also useful to play around with a debugger, which is really simple:

1. Write debugger; somewhere in your code
2. In case you use VS Code, run "Debug: Attach to Node Process"
3. Select server.ts

Then, whenever your code runs over the debugger line, it'll stop and allow you to inspect. It helps me a ton in such situtations.