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

Record type argument for client #251

Closed
scriptcoded opened this issue Oct 12, 2023 · 5 comments
Closed

Record type argument for client #251

scriptcoded opened this issue Oct 12, 2023 · 5 comments

Comments

@scriptcoded
Copy link

Hey there!

While working on a side project of mine using PocketBase I found it somewhat cumbersome to manually provide types for each record query. I could wrap everything in a data layer but it made me wonder if there was a way to provide one singe type with all types contained to the client, which there wasn't. Would you be interested in a PR providing this functionality? In my mind it shouldn't be too hard (though we all know that's never true). I'm thinking something in the lines of

import PocketBase from 'pocketbase'

import { PostsRecord, UsersRecord } from './pocketbase-types'

type PocketbaseTypes = {
  records: {
    users: UsersRecord
    posts: PostsRecord
  }
}

const pb = new PocketBase<PocketbaseTypes>('...')

It would also open up for tools like typed-pocketbase to simply export a single type and have everything typed automagically.

Cheers! 😄

@ganigeorgiev
Copy link
Member

I'm not sure that I understand the suggested proposal.

Contributions for new features are welcomed but there are no promises that it will get merged or reviewed in a timely manner (see also pocketbase/pocketbase#3271).

There are plans to provide auto generated type definitions with the JS and Dart SDKs but for now other tasks are with higher priority and it is left aside (eventually the JS SDK part will be handled as part of #152).

@scriptcoded
Copy link
Author

I totally understand, maintaining takes time. I won't be creating a fully functional PR unless you've given the clear. Both per the contribution guidelines but also out of respect for my own time. I'd be happy to explain in detail what I'm thinking, but if you're just interested I'm thinking something in the likes of what Supabase does, but just the client type part, not generating the types themselves. Maybe it could be seen as a prerequisite to #152.

Keep up the good work and I'm sure you've already thought about it, but lots of people including me are probably up for helping out!

@ganigeorgiev
Copy link
Member

ganigeorgiev commented Oct 12, 2023

If I'm reading the Supabase docs correctly, then I guess similar behavior can be achieved by using type assertion. The only thing that prevent us do it easily at the moment is that the RecordService at the moment doesn't accept a generic type. If we add support for that and replace all individual T = RecordModel with T = G (where G is the global service type) then you'll be able to do something like:

interface TypedPocketBase extends PocketBase {
  collection(idOrName: 'yourCollection1'): RecordService<Type1>
  collection(idOrName: 'yourCollection2'): RecordService<Type2>
}

...


const pb = new PocketBase("...") as TypedPocketBase;

const record = await pb.collection('yourCollection2').getOne('RECORD_ID') // should be returned as Type2

This weekend I'm planning a PocketBase v0.19.0 release and will see if nothing unexpected show up I'll consider updating the JS SDK too to add support for the "global" RecordService generic type.

@scriptcoded
Copy link
Author

That sounds like a good and simple solution. Want me to open a PR for it or will you manage it yourself?

@ganigeorgiev
Copy link
Member

The above should be supported with JS SDK v0.18.3 release.

The README was also updated with an example.

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

No branches or pull requests

2 participants