Documentation still relevant if using v5 schema typed client?

[juw177]

I am new to feathers and having trouble understanding data modelling and services section of the docs.

With the new dove v5 feathers typed client bundle, I am able to import the schema as a type like so:
import { User } from 'feathers-api/lib/services/user/user.schema'

But the documentation is telling us to define types. Can we use the schema type here instead?
https://feathers-pinia.pages.dev/guide/data-modeling.html

There is some info about implicit models, I cannot tell if this is still relevant if we already have a schema model.
https://feathers-pinia.pages.dev/migrate/models.html

There is also documentation about the service interface which seem to have no usage of types
https://feathers-pinia.pages.dev/services/

If anyone can clarify how the above works with schema types, that will be great! Ideally, the outdated example projects can also be updated?

The getting started guide has the api working but does not explain if client / service configs are needed. Can I stop here and write my own api.service calls every time I need it? Then what is the benefit of all the other API config features? Maybe I was naive to think that I just need to pass it the api service name and the schema and the rest syncs with the store?

[gorango]

This is documented in the data-modeling#complete-example-with-types where you can replace the Book in the example with your imported schema.

I currently do something like this:

import type { PiniaServiceConfig, ServiceInstance } from 'feathers-pinia'
import type { User as BaseUser } from 'my-feathers-api'
import type { Tab } from './tabs'

export interface User extends BaseUser {
  tabs?: Tab[]
}

export const usersServiceConfig: PiniaServiceConfig = {
  setupInstance: (user: ServiceInstance<User>, { app }) => { // <-- this is what you're after
    app.pushToStore(user.tabs, 'tabs')
    app.defineVirtualProperties(user, {
      tabs(user: User) {
        return app.service('tabs').findInStore({ query: { userId: user.id } }).data
      },
    })
    return user
  },
}

The docs could benefit from more explicit types examples - specifically, the migration guide that you also linked for implicit modelling under the "New API" tab.

A lot of work was just recently done on Typescript in the project so the implementation details have been somewhat fluid until fairly recently.

[juw177]

Thank you that was helpful.

Is there a way to get type for service API method responses? eg, Typescript does not see the type of service find().data so I need to add "as any" before I can assign it to something.

[juw177]

Im following the migraion to models code but stuck at creating the store.

Sorry for the newbie questions but in the set up guide it does not mention store definitions:
https://feathers-pinia.pages.dev/setup/vite.html

There seem to be a few different snippets available on creating the store, what is the correct way?
https://feathers-pinia.pages.dev/data-stores/#creating-a-data-store
https://feathers-pinia.pages.dev/guide/setup#pinia
https://github.com/marshallswain/feathers-pinia-vite/blob/e2df21f312a4994fab2b8661782c07bcab38e648/src/stores/service.users.ts

edit: also I didn't find a clear explantion for when to use the regular service api methods vs the in store service methods. eg, When using createInStore, does this sync with the server or it only gets created in store?

[gorango]

You're on the right track with the vite setup guide. The rest of the links you shared are probably not going to be helpful - the first one is specific to stand-alone stores and the second two are out of date with the latest version of the package.

If you follow the setup guide, in your src/feathers.ts when you call createPiniaClient the result should return a fully typed feathers client interface based on your imported schema from your API, so you shouldn't have to do anything else to connect to your services.

You can also look at the Client API for all options and examples for customising services. This is where I thought you were stuck when I initially responded. You only need to do this if you are trying to extend an individual service or connect associated services. If you wanted to include my example above in your config, you would do something like:

createPiniaClient(feathersClient, {
  idField: '_id',
  whitelist: ['$customLocalParam'],
  paramsForServer: ['$customServerParam'],
  skipGetIfExists: true,
  services: {
    users: usersServiceConfig
  }
})

Good luck. Following the vite setup guide should get you up and running.

[juw177]

Thanks @gorango . Yes I see that there is a storeName in the service config and I can set up the typed instance. I think the confusion is, if we don't define something like useTaskStore, how does a Vue component interact with the store to get real time updates from feathers?

[gorango]

To use the store in a component, you can directly import it like:

import { api } from `~/feathers` // your local feathers.ts file

const data = await api.service('tasks').find()

You can also set up a useFeathers composable to auto-import the store in your components as needed:

const { api } = useFeathers()

const data = await api.service('tasks').find()

Whenever you receive data from the api it will be reactive.

You can wrap individual stores in composables but I don't think that's necessary.

[juw177]

Hi @gorango sorry to bother again, in the doc update where we are using ServiceInstance for our types, it is working great and I am really enjoying using it. But when I use defineVirtualProperties, these are not visible in the ServiceInstance type and the project will not compile. Is there any work around for this?

edit: I tried defining a type with virtual properties and combining with the schema a bit like the BookIncludes example but ran into other mismatches, plus it means I will need to modify schema model for all references.

// Define types for related data
export interface BookIncludes {
  pages: PageWithIncludes[]
  creator: UserWithIncludes
}
export type BookWithIncludes = ServiceInstance<Book & BookIncludes>

For now, I have just gone with putting the virtual properties in the feathers backend schema which is not elegant but it is clean.