Thoughts on adding some-sort of output customisation

[AndrewLeedham]

I have been working on adding this package to one of our internal projects, and in order to facilitate the needs there I have forked this package and some modifications: AndrewLeedham@5a4c117. The main change is exporting to the type CMSEntry<ContentTypeId, Fields> instead of Entry<Fields>, as well as exporting a Union of all the types and some other minor tweaks. I am curious on your thoughts on a first class way of supporting something like this, ideas I have been considering:

1. Put a PR in to the contentful.js repo to add the strongly typed Entry as an option, something like:

export interface Entry<Fields, ContentTypeID extends string = string> {
    sys: Sys<ContentTypeID>;
    fields: Fields;
    toPlainObject(): object;
    update(): Promise<Entry<T, ContentTypeID>>;
}

and extend this repo to export things in the format I am after.

2. Add a method to the CFDefinitionsBuilder which exposes the ts-morph project, so it can be modified before generating the types.

3. Integrate https://github.com/webpack/tapable into the package so the rendering can be modified as needed.

[marcolink]

1. Put a PR in to the contentful.js repo to add the strongly typed Entry as an option, something like:

I'm not sure how urgent these changes are for you, but if you can wait, this might be something for you!

2. Add a method to the CFDefinitionsBuilder which exposes the ts-morph project, so it can be modified before generating the types.

I'd be fine with exposing the ts-morph project 👍

3.Integrate https://github.com/webpack/tapable into the package so the rendering can be modified as needed.

I think tapable is a great and powerfull tool. But it comes with a complex API that we would add on top.

A general question, are you using it as CLI, or do you interact with CFDefinitionsBuilder builder directly?
I could imagine that we can register different types of render callbacks, to transform the input in different situations and for different prop renderers. Would that help to solve your problem?

[AndrewLeedham]

I'm not sure how urgent these changes are for you

Not an immediate rush, I have things working with my custom fork. But it is not an ideal solution, as updates to the main repo will be difficult to back-port.

this might be something for you!

This seems to be specific to queries against field data right? What I am wanting is sys.contentType.sys.id to be strongly typed as part of Entry, e.g. instead of string it is a literal type of the relevant ID.

A general question, are you using it as CLI, or do you interact with CFDefinitionsBuilder builder directly?

Directly interacting with CFDefinitionsBuilder.

I could imagine that we can register different types of render callbacks, to transform the input in different situations and for different prop renderers. Would that help to solve your problem?

That is essentially what I was getting at with tapable, callbacks would work just as well 👍

[marcolink]

@AndrewLeedham I created a new PR #123 addressing this issue.

Would your case be covered with this? (still WIP though)

[marcolink]

version 2.0.0 which features custom rendering just got released