-
-
Notifications
You must be signed in to change notification settings - Fork 761
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
infer multi
, id
& paginate
of service.options
#3012
Comments
This is interesting - I made a question on discord about the return type of the find method and how to handle it. ( https://discord.com/channels/509848480760725514/1062772689913266216/1062772689913266216 ). If the service return type "understood" the pagination property it would make (my!) code much much neater! There might be a better way to handle it currently but it would be great to have this type inference! |
I noticed using the v5/Dove client that the return type is correct and changes according to the use of |
Yes, that's true, if you do |
This is actually the correct type for a before hook, the validation step for multi isn't done until the database adapter. So technically a create before hook may receive array type data. |
Problem:
data
forcreate
isT
orT[]
, even true for services withmulti: false
/multi: { create: false }
.id
forpatch
&remove
isNullableId
, even for services withmulti: false
/multi: { patch: false, remove: false }
find
isResult[] | Paginated<Result>
, even for services withpaginate: false
{ $select: ['email'] }
does not returnPick<Result, 'email'>
but the 'full' typeResult
instead. Even thoughPick<Result, 'email'>
wouldn't be the correct type either. It has to bePick<Result, 'email' | Service['options']['id']>
The root of these problems above is, that the type of
service.options
is not considered in the service methods. TheAdapterBase
already has a genericOptions
. We only need to infer the type and fall back to the general types, if it cannot infer.Other things to consider:
es6 classes are tedious to work with for heavy TS work like inference. We already saw this for
feathers-pinia
and moved away from model classes. I think we should move away from es6 classes for adapters & services and make a customuseService(...)
function. But I guess I need to open another issue/discussion for this.The text was updated successfully, but these errors were encountered: