Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help us improve 🍉's TypeScript support #1516

Open
6 tasks
radex opened this issue Feb 2, 2023 · 5 comments
Open
6 tasks

Help us improve 🍉's TypeScript support #1516

radex opened this issue Feb 2, 2023 · 5 comments
Labels

Comments

@radex
Copy link
Collaborator

radex commented Feb 2, 2023

0.25 came with a huge improvement in the quality and maintainability of 🍉's TypeScript types. There were some teething problems, requiring a few patch releases, and no doubt the increased type coverage revealed new TS errors that weren't there before.

Anyway, thanks a lot to @sidferreira @paulrostorp @enahum @mlecoq for their contributions

You can help. Here's a few TS maintenance items that need to be done:

  • hook up prettier to run over .d.ts
  • in package.json there are outdated TS-related dependencies… I'm not even sure that all of them should be there, given that much of the TS checking lives in examples/typescript
  • remove // @flow comments from d.ts's
  • there's tslint, but I don't think it's hooked up to run anywhere? shouldn't it be a part of yarn ci:check ?
  • add usage of more 🍉 APIs to examples/typescript to test type-checking
  • add typescript types to documentation
@lucaswitch
Copy link

Hello @radex, i just added some Typescript support on the Setup docs website section.
Can i continue or we need to change something?

@radex
Copy link
Collaborator Author

radex commented Jul 31, 2023

@lucaswitch PR?

@lucaswitch
Copy link

Just added the PR #1636

@dexter-stpierre
Copy link

Hoping to find time to contribute some types for this soon. FWIW I thought I'd let you know that tslint was deprecated in 2020. From what I can tell the eslint settings should handle linting the .ts files, but I can confirm when I find time to contribute to the types https://www.npmjs.com/package/tslint

@BrunnerLivio
Copy link

BrunnerLivio commented May 13, 2024

I created a little wrapper around the tableSchema function to make the column names & table name types secure and synched with the model.

import {Model, tableSchema} from '@nozbe/watermelondb'

type TableSchema = Parameters<typeof tableSchema>[0]
type Column = TableSchema['columns'][number]

type WatermelonModelFields = keyof Model
type Class<TModel extends typeof Model> = TModel extends {
  new (...args: any[]): infer U
}
  ? U
  : never

/**
 * Removes all fields that are inherited from the Watermelon Model class
 */
type ModelFieldNames<TModel extends Model> = Exclude<
  keyof TModel,
  WatermelonModelFields
>

export type ModelSchema<TModel extends typeof Model> = TableSchema & {
  name: TModel['table']
  columns: (Column & {
    name: ModelFieldNames<Class<TModel>> extends never
      ? string
      : ModelFieldNames<Class<TModel>>
  })[]
}

export const tableSchemaTypesecure = <
  TModel extends typeof Model = typeof Model,
>(
  arg0: ModelSchema<TModel>
) => tableSchema(arg0)

Usage:

class UserModel extends Model {
  // Needs to be `readonly` so that the type can be inferred
  static readonly table = 'users'

  @field('name') name!: string
}

const userSchema = tableSchemaTypesecure<typeof UserModel>({
  name: 'users',
  columns: [{name: 'name', type: 'string'}],
})
Screenshot 2024-05-13 at 19 45 05 Screenshot 2024-05-13 at 19 44 52

If you're interested I'll gladly try to make this work upstream & create a PR :)

Though there are better ways to solve this problem -- this would just be a simple way to provide typescurity without introducing a breaking change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants