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

Access documents of the current collection in transform #268

Closed
wottpal opened this issue Aug 24, 2024 · 7 comments · Fixed by #290
Closed

Access documents of the current collection in transform #268

wottpal opened this issue Aug 24, 2024 · 7 comments · Fixed by #290
Assignees
Labels
enhancement New feature or request

Comments

@wottpal
Copy link

wottpal commented Aug 24, 2024

Hey @sdorra, I would really appreciate if you could find a way to make this possible. Referring to #245.

My current workaround (probably interesting for you @Kuzry, too) is defining a dummy/helper collection first (with only very few schema attributes that all pages share like slug or title). And then I can iterate over those via context.documents(helpers).map(…) as usual.

Though, for performance & DRY reasons I would highly appreciate being able to access all pages in the transform function w/o that.

My suggestion: As I understand it's impossible to make them accessible post-transform, I would suggest having some kind of pre-transform document collections of the current collection being accessible during transform (hope that's understandable).

There are just so many use cases this would enable:

  • Very helpful in multilingual setups where I want to determine the internationalized version of the current page.
  • If I have some kind of embeddings and want to pre-compute "related pages".
@sdorra
Copy link
Owner

sdorra commented Aug 25, 2024

I believe that it is already possible to access the documents of the collection in the transform function:

documents: (collection) => {

It is probably just a type problem.

documents<TCollection extends AnyCollection>(

At first glance it looks right. I'm on vacation for a week now, but I'll take a look at it when I get back.

@sdorra sdorra self-assigned this Aug 25, 2024
@sdorra sdorra added the enhancement New feature or request label Aug 25, 2024
@wottpal
Copy link
Author

wottpal commented Aug 26, 2024

Wow this indeed seems to work, though I tried this before. 🤔 Amazing!

Now I only need some kind of equivalent for the GetTypeByName generic to get the "pre-transform" type of a collection document.

@sdorra
Copy link
Owner

sdorra commented Aug 31, 2024

Okay, I've looked into it, and I believe it is not possible to get the types right for the documents function of the Context. This is because the function requires the collection as input, and it uses the type of the collection to determine the type of the resulting documents. However, the type of the collection is based on the result of the transform function. Therefore, we cannot use the type in a function that is required to determine the type. Does this make sense?

We could introduce a new API to retrieve the documents of the current collection. The context already includes a collection. We could add a documents function without any parameters. An example usage could look like this:

import { defineCollection, defineConfig } from "@content-collections/core";

const posts = defineCollection({
  name: "posts",
  directory: "sources/posts",
  include: "*.md",
  schema: (z) => ({
    title: z.string(),
    description: z.string(),
  }),
  transform: async (post, { collection }) => {
    const docs = await collection.documents()
    const idx = docs.indexOf(post);
    const prev = docs[idx - 1];
    const next = docs[idx + 1];

    return {
      ...post,
      prev,
      next
    }
  }
});

export default defineConfig({
  collections: [posts],
});

But I'm not sure about the naming. It's clear that the ctx.documents function is for retrieving documents from other collections, while ctx.collection.documents is for documents from the current collection?

sdorra added a commit that referenced this issue Sep 2, 2024
Extend the context collection with a documents function,
which returns all documents of the current collection.

Closes: #268
@sdorra
Copy link
Owner

sdorra commented Sep 2, 2024

@wottpal, could you please check if the functionality of #290 meets your requirements?

To install the preview packages, add the package you need as described in this comment:

#290 (comment)

The documentation for the new feature can be found here:

https://content-collections-otminv2j1-nitilon.vercel.app/docs/transform#access-sibling-documents

@wottpal
Copy link
Author

wottpal commented Sep 3, 2024

Hey, @sdorra, yes #290 looks pretty useful indeed.

Though I was not able to test it, even though I've installed all the pkg.pr.new deps with bun. Context.collection still only has the name & directory attributes for me (also force-reinstalled, restarted VSCode, etc.)

CleanShot 2024-09-03 at 09 02 27@2x

sdorra added a commit that referenced this issue Sep 3, 2024
Extend the context collection with a documents function,
which returns all documents of the current collection.

Closes: #268
@sdorra
Copy link
Owner

sdorra commented Sep 3, 2024

@wottpal you are right the github workflow has used the main branch instead of the pr head. Now the packages should contain the code from the pr. If your package manager does not refresh the packages with pr suffix (290) you could use 639c2ea as suffix e.g.:

    "@content-collections/core": "https://pkg.pr.new/sdorra/content-collections/@content-collections/core@639c2ea",
    "@content-collections/mdx": "https://pkg.pr.new/sdorra/content-collections/@content-collections/mdx@639c2ea",
    "@content-collections/next": "https://pkg.pr.new/sdorra/content-collections/@content-collections/next@639c2ea",

@wottpal
Copy link
Author

wottpal commented Sep 4, 2024

Works & works 👌 ✅

sdorra added a commit that referenced this issue Sep 4, 2024
Extend the context collection with a documents function,
which returns all documents of the current collection.

Closes: #268
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants