Type-safe Populated Serialization

[isaacnass]

Hey! Not sure if I'm missing something super straightforward, but I'm having an issue with getting the "expected outcome" type of a deep population. This is due to the actual fields being housed in the $. Are there any utility functions I can use that will give me type safety for the return types of my API endpoints?

[B4nan]

If you want help, you need to provide some code, I really don't understand what you want :]

The $ props are just for reference wrapper and they are type safe getters (they are there all the time, but for TS only when you have the right populate hint = when we know it will give you loaded entity).

But as you are talking about serialization, I don't understand how that is connected to reference wrapper and the $ properties, those are not present in the serialized form. And unfortunately the DTO won't be strictly typed anyway - it is almost impossible to do it properly, there are simply too many moving parts (population, partial loading, virtual properties, optionallity). I will try to make it better in v5 (as making things more strict is in fact a BC), but it will never be perfect. Even if it would be possible, it would result in very slow and performance heavy usage, which in the end makes the DX even worse.

[isaacnass]

I guess what I'm asking is if there is any way to deeply unwind the $ field when calling toObject or toJson, as it would make validation and unit testing a breeze.

Right now if I have a JSON schema that essentially translates to the following interface:

interface SomeApiResp {
  organization: BaseOrganizationPrimitives & {
    users: BaseUserPrimitives[]
  }
}

That contract is perfectly satisfied at runtime with a simple orgRepo.findOne({}, { populate: { users: true } }).
However if I actually want to create a service that shares those types, there's no way to do so without removing the type safety:

const psuedocodeApiGrabOrgWithUsers = async (): Promise<SomeApiResp> => {
  const org = orgRepo.findOneOrFail({}, { populate: { users: true } })
  return { organization: (org.toObject() as unknown as any) } // This is _required_ to satisfy strict ts
}

EDIT: Btw I use ts-morph, I know that plays with this a bit in regards to the references

[B4nan]

I still don't follow, references are unwrapped in toObject() (which is used also under the hood of toJSON(). Or are you talking just about typings issues?

The reference wrapper (IdentifiedReference) is optional, you don't have to use it.

Btw there is no point in casting to unknown if you then re-cast it to any. Also in your code you are missing await.

[isaacnass]

Btw there is no point in casting to unknown if you then re-cast it to any. Also in your code you are missing await.

Sorry was pseudocoding >:D

Or are you talking just about typings issues?

Yessir! The runtime is hunky-dory, our team is just looking to have strong type safety.

The reference wrapper (IdentifiedReference) is optional, you don't have to use it.

While that would fix this issue, then we'd just lose type safety when we're not populating the relations

To be very frank I guess I'm not understanding why toObject doesn't do this already, this seems like a common need.

Hope I'm not being too critical or anything... it's been an absolute pleasure using Mikro so far!!! 💯

[B4nan]

Planning to improve on strictness in v5 in general, as in my eyes it is a breaking change, but it will happen soon and most probably for toObject() too, at least partially.

The thing is, it will never be perfect, due to all the possibilities. On the type level, we just know there is a reference wrapper or a naked entity - but we do not have the information whether its loaded or not (edit: with LoadedReference type hint we actually do, so that is indeed what can be improved), which has direct impact on what the serialized output will be. Another variable is eager loading, next one is partial loading (FindOptions.fields), both have effect on what toObject() returns, both are not present on the type level. And don't forget property serializers! :]

With toJSON() it is even less predictable, as you can have custom implementation with conditional logic (granted you can improve the return type manually that way).