Specifiying custom types for fields

[brudil]

We use branded/tagged types a lot across our codebase, allowing us to represent primitives that have been "blessed" in some way. A lot of the time this is used in conjunction with Zod.

It would be great if Joist could support configuration to specify a type for the codegen to use instead of the pg->ts mapped type.

This would essentially behave like the superstruct option with FieldConfig but with no change to the setter/getter implementation itself, purely the resulting type for that field.

"LoginAudit": {
      "fields": { "ipAddress": { "type": "IpAddress@src/types" } },
    },

export type IpAddress = string & { type: 'ip' }

I'll be curious to hear if this is something you would like Joist to entertain as I'd be happy to work on a PR.

[stephenh]

Hi @brudil ! Yep, that use case makes sense, and it'd be great if you wanted to work on a PR.

The type key would probably be added around here:

https://github.com/stephenh/joist-ts/blob/main/packages/codegen/src/config.ts#L13

And then around in here:

https://github.com/stephenh/joist-ts/blob/main/packages/codegen/src/EntityDbMetadata.ts#L348

Is probably a good place to do the config lookup and replace the default JS type with the config type.

I could see eventually this becoming more complicated if users wanted to bring their own custom serde to the table, but since you're just using branded types, that at runtime are the same primitives anyway, afaiu we wouldn't need that yet.

(Also, for testing, if you wanted to add an authors.ip_address column to our integration-test schema, to show it working end-to-end, that'd also be great.)

Thanks!

[brudil]

Funny you mention serdes. We would be looking to contribute support for that in the future. We use a couple of ValueObjects to represent bits of data.

PasswordValue

export class PasswordValue {
  constructor(public readonly hash: string) {}

  static fromPlainText(str: string) {
    return ResultAsync.fromPromise(
      (async () => new PasswordValue(await argon2.hash(str)))(),
      () => new InternalError('password creation error')
    );
  }

  static fromEmpty(): PasswordValue {
    return new PasswordValue('');
  }

  static fromHash(hash: string): PasswordValue {
    return new PasswordValue(hash);
  }

  get isEmpty() {
    return this.hash === '';
  }

  matches(str: string) {
    return ResultAsync.fromPromise(
      argon2.verify(this.hash, str),
      () => new InternalError('password failure')
    );
  }
}

We've gotten around this so far by using some additional setters and getters on our models, but we do hit an issue around required fields and their constructors requring the primitive.

I'll leave it out of scope for the above PR, but if you have any thoughts around supporting this it would be great to hear.

[stephenh]

Good question! My first guess would be a serde field in the joist-config.json, right next to the type field you just added...

Little unclear what the API would be; right now each of Joist's serde classes have their own ~bespoke constructors:

https://github.com/stephenh/joist-ts/blob/main/packages/orm/src/serde.ts#L199

But we could probably make an API that is a superset of what each of the current serdes needs, so a user could do something like:

class PasswordValueSerde implements Serde {
  constructor(opts: { ...things like field name, column name, db type... })

  ...serde impls...

I technically don't love the current names of the serde methods, like dbValue, mapToDb, etc., the names just aren't that intuitive, so would get nervous about turning those into a public API just as-is, but we could clean up/bikeshed those names are part of making a custom serde api.

[brudil]

Custom types landed in https://github.com/stephenh/joist-ts/releases/tag/v1.87.0 and Serde landed in https://github.com/stephenh/joist-ts/releases/tag/v1.91.0