Open brandonroberts opened 10 months ago
Hi @brandonroberts, I can work on this. There are a few things I wanna discuss.
Currently ContentFile
interface is used for both injectors - injectContentFiles
and injectContent
.
injectContentFiles
returns a list of file attributes created by the content plugin..injectContent
returns the same set of attributes but with content. However, the attributes are pulled from the frontmatter in the parseRawContentFile
function. If we want to create additional attributes (like the summary) in the content plugin, we would need to change the flow since parseRawContentFile
uses its own mechanism and has no access to the plugin data at this point.
We can modify CONTENT_FILES_TOKEN
to produce content wrapped in a promise, along with attributes, by simply attaching them in the factory function.
The other way is to inject the CONTENT_FILES_LIST_TOKEN
into the injectContent and apply attributes from there.
The goal in both solutions is to pass previously generated attributes by the content plugin into parseRawContentFile
, so we get consistent results.
Also, I'm wondering about creating two separate interfaces, one for the files list and the other for the file. I want to point out that injectContentFiles returns a ContentFile
with an optional content field, but we are 100% sure that it's not there.
export interface ContentFileMeta<
Attributes extends Record<string, any> = Record<string, any>
> {
filename: string;
slug: string;
attributes: Attributes;
summary?: string;
}
export interface ContentFile<
Attributes extends Record<string, any> = Record<string, any>
> extends ContentFileMeta<Attributes> {
content?: string;
}
This allows us to use them accordingly:
export function injectContentFiles<Attributes extends Record<string, any>>(
...
): ContentFileMeta<Attributes>[]
export function injectContent<
Attributes extends Record<string, any> = Record<string, any>
>(
...
): Observable<ContentFile<Attributes | Record<string, never>>>
We may also don't need to have summary in the injectContent
, so the interfaces would look slightly different and we would not change the flow.
Thanks @Dyqmin, good poins.
@mhartington had the initial idea and already said they would take a go at it, so I'll leave it to them first before you start any work there.
Which scope/s are relevant/related to the feature request?
content
Information
Hugo supports providing content summaries for each content file
https://gohugo.io/content-management/summaries/
<!--more-->
marker.We currently only support using the frontmatter for the
summary
, but this could be a configurable option in the@analogjs/platform
plugin that's passed to the internalcontentPlugin
that provides the list of parsed frontmatter.Example:
The
summary
property would also be added to theContentFile
interface. It would be opt-in initially.Describe any alternatives/workarounds you're currently using
No response
I would be willing to submit a PR to fix this issue