Add minDepth to relationship field to control generated type

[silveltman]

Right now, the generated type of a relationship is as follows

myrelationshipfield?: string[] | Collection[];

This is very annoying, because a string is string[] is never returned when using a depth for the API requests, right?

If so, I would like minDepth setting on the relationship field to turn the generated type into myrelationshipfield?: Collection[];

[matthijs166]

Why is this annoying? And what does improve by doing this?

Also, I think if the collection suddenly does not exist any more it returns the saved field in the db (a string) or you got the following case: Collection2 has a relationship field to Collection1 this returns the full object of Collection1 when retrieving Collection2. Now if we got a Collection3 that has an relationship to Collection2 and the depth is max 2 the relationship on Collection2 returns just the ID.

[gabrielkuettel]

I find it pretty annoying to have to check typeof === 'string' throughout my code when accessing collections that have many nested relationships. Any solution around this would be great.

[matthijs166]

Understandable, only thing is (and that's my previous point) there are some edge cases. You can try recasting the collection type to your own and force the relationship to be that collection. It's a bit hacky but if it works it works!

Here is an example:

type Collection = {
  fields: any;
  relationField: string[] | CollectionTwo[];
};

type NewCollection = Omit<Collection, 'relationField'> & { relationField: CollectionTwo[] };

In the recasting process you can also check if it is a string or not and otherwise default to an empty array.

Sometimes if you find yourself implementing this kind of stuff or something annoys you, there can be a chance that there might be an opportunity to learn something new about the way you're using it. But yeah, I also find it way easier to implement a fix like this than change the way I program.

Tip is to look to enable strict typing and use null checks when calling properties of the relation Field that can be a string.

[gabrielkuettel]

I did something similar to that initially, but then decided against it because I want the convenience/safety of relying on the generated types. Now I'm using utility functions that take the collection as an argument, and returns null or false if it's undefined or pointing to the relationship ID. I can live with this approach but curious what other people are doing.

export function isRelationship<Collection>(obj: any): obj is Collection {
  return obj && typeof obj !== 'string'
}

export function checkRelation<Collection>(obj: any) {
  if (!isRelationship(obj)) {
    return null
  }

  return obj as Collection
}

// Example usage
const imageUrl = checkRelation<Media>(post.image)?.url || ''

[matthijs166]

Looks like something I will write.

Also think that you can also write it a bit shorter:

export function checkRelation<Collection>(obj: any): Collection | null {
    return obj && typeof obj !== 'string' ? obj : null;
}

const imageUrl = checkRelation<Media>(post)?.image.url ?? ""

[matthijs166]

The discussion boils down to: How to solve the following type error the cleanest way possible:

type Media = {
    title: string
    image: {
        url: string
    }
}

const post : Media | string = "Hello World!"

// gives error "Property 'image' does not exist on type 'string'.ts(2339)"
const imageUrl = post?.image?.url ?? ""