Firestore Complex Types handling

[Willy Ovalle]

In #56 we started re-exporting The way Typescript works, types are not available at runtime. If you want to cast Firestore's complex types into your custom classes, you need to tell Typescript the class it should cast it to... via a Decorator.

This issue is more of an exploration in this topic. More information is needed to fully implement a flexible solution.

Acceptance criteria:

• Explore each of the Firestore Data Types, create unit tests for complex types.
• Get rid of class transformers @type
• Create a new Decorator (@Transform?) to store field's type-casting information and (probably) some constraints.
• The new decorator MUST provide a way to call custom constructors and let the owner of the class "construct" its object. This is to get rid of the current limitation in which in order to parse a GeoPoint, you must provide a class with public latitude and longitude fields
• The new Decorator MUST enforce the user to provide a way to serialize and deserialize data. How we will be able to store an object with a custom GeoPoint class if we don't now how to serialize it back?

[Eric Liu]

Hi @wovalle - we're running into this issue in validating complex data types using nested classes with fireorm. Is there an update on this issue? Is there anything that we can help with?

[Willy Ovalle]

Hey @ericliu121187, somehow I missed this notification.

Sadly there are no updates, I haven't had time to tackle this issue. What are you trying to accomplish?

[Eric Liu]

Hi @wovalle , no worries. Let’s say we are creating a Post document via fireorm.

await getRepository(Post).create(
  Post.create({
    // ...data
  }),
);

@Collection(‘posts’)
export class Post {
  @Expose()
  @IsString()
  public readonly id!: string;
  /**
   * Metadata
   */
  @Expose()
  @IsObject()
  public readonly metadata!: Readonly<{
    author: Readonly<{
      name: string;
    }>;
    data: Readonly<{
      entities: Readonly<{
        hashtags?: readonly unknown[];
        urls?: readonly unknown[];
        tags?: readonly unknown[];
      }>;
      description: string;
    }>;
  }>;

  static create(
    data: Partial<Post>,
  ): Post {
    return plainToClass(Post, data);
  }
}

Am I correct in saying that the nested values in metadata would not be validated?

If not, do you have any suggestions in how we could validate it? Writing a custom validator isn't ideal here bc we want to work with classes to add custom methods to values + ideally, the validation would be recursive out-of-the-box.

What are your thoughts here?

[Willy Ovalle]

Not an expert with validation but I think they won't be validated. In my case I'd try to flatten more the structure to have simple fields that can be easily validated.

[Jan Demel]

Hello guys. Is there any progress with this one?

[Eric Liu]

@hondem Not on my end. We decided to punt on validating nested data. My instinct is that there could be 2 approaches.

A. Fireorm can validate recursively
B. Writing a custom validator

[Yunus]

Any update on this?