feathers-pinia

Use storeRelated to Distribute Data

A new storeRelated method has been added to each Feathers-Pinia Client:

setupInstance(post, { app }) {
  app.storeAssociated(post, {
    author: 'authors',
    comments: 'comments',
  })
  const withDefaults = useInstanceDefaults({ authorIds: [] }, post)
  return withDefaults
},

Now when you create an instance with data matching those keys, the related data will move to the associated service stores.

const post = api.service('posts').new({
  title: 'foo',
  author: { id: 2, name: 'Steve' },
  comments: [
    { id: 1, text: 'comment 1', authorId: 1, postId: 1 },
    { id: 2, text: 'comment 2', authorId: 1, postId: 1 },
  ],
})

post.createInStore()

If you inspect post in the above example, you'll find the following:

• post.author is an author instance, already created in the authors service store.
• post.comments is an array of comment instances, already created in the comments service store.
• The post.author and individual records in post.comments are all reactive. So if they get updated in their
  stores, the values on post will reflect the change.
• The post.comments list length is not reactive.
• We still have to manually call post.createInStore() afterwards to add it to the posts service store.
• Finally, all of the values have been rewritten as non-enumerable, so if you call post.save(), the related data will
  not be sent in the request to the API server.

🐜 Bugfix: service.count() return values fixed

Calling service.count({ query: {} }) no longer returns items in data and instead returns a paginated response like this:

{
  data: [],
  limit: 0,
  skip: 0,
  total: 55 // or whatever the total for the query you provided
}

It's now possible to customize the service stores using the customizeStore global- and service-level configuration options. Here's what you need to know.

• The global-level customizeStore receives the default store and can customize it.
• The service-level customizeStore receives the globally-customized store and can further customize it.
• It's possible to completely overwrite values in the default store, so use care.

createPiniaClient(feathersClient, {
  pinia: nuxt.$pinia,
  // below are configurable per service in the `services` object.
  idField: '_id',
  customizeStore(defaultStore) {
    // You can directly modify the defaultStore object
    defaultStore.globalValue = ref(true)
  }
  services: {
    contacts: {
      // customize the store for a single service
      customizeStore(defaultStore) {
        defaultStore.contactsValue = ref(true)
        return { otherValue: true } // returned values will be merged, as well
      }
    },
  },
})

This release fixes an error where the Application types didn't match when calling createPiniaClient(feathersClient, etc }).

The pagination params are now properly considered while working with useFind in local mode (where paginateOnServer is false)

You can now create data stores to handle data with an API consistent with the Feathers-Pinia service interface.

Create a Data Store

import { useDataStore } from 'feathers-pinia'
import { createPinia, defineStore } from 'pinia'

const pinia = createPinia()

const useStore = defineStore('custom-tasks', () => {
  const utils = useDataStore({
    idField: 'id',
    customSiftOperators: {}
    setupInstance: (data: any, { api, service, servicePath }) => data
  })
  return { ...utils }
})
const store = useStore(pinia) // --> See API, below

// Adds HMR support
if (import.meta.hot) {
  import.meta.hot.accept(acceptHMRUpdate(useStore, import.meta.hot))
}

Read more in the documentation: http://localhost:5173/data-stores/

Added docs for createPiniaClient

https://v3.feathers-pinia.pages.dev/guide/create-pinia-client.html

Global Configuration Merging

Service-level configuration is now intelligently merged with the global configuration:

• arrays are concatenated
• primitives are overwritten by the service
• setupInstance run first at the global level then the service level

Global setupInstance

The setupInstance option is now also a global configuration property. It runs before any service-level setupInstance function.

setupInstance now has a utils argument

setupInstance now receives a utils object as its second argument. The utils object includes

• api: the Feathers-Pinia client
• service: the current service
• servicePath: the path of the current service.

This allows more flexibility of accessing app and service-level scope while keeping setupInstance functions in a separate file.

All sift operators whitelisted, by default

There's no need to manually add a sift operator to the whitelist. They've all been enabled, internally. This only applies to findInStore queries (it doesn't change the remote API configuration)

• $in
• $nin
• $exists
• $gte
• $gt
• $lte
• $lt
• $eq
• $ne
• $mod
• $all
• $and
• $or
• $nor
• $not
• $size
• $type
• $regex
• $where
• $elemMatch

The unplugin-auto-imports-preset has been updated to export the following utilities:

• useFeathersInstance
• useInstanceDefaults
• useDataStore
• useAuth
• createPiniaClient

This release assures that SSR hydration correctly happens when using useFind.

Service Events

Service events now properly sync to the store. Keep in mind that service events are batched, by default, to 20ms intervals, so any tests you write should take that into account. You can change the batch interval using the debounceEventsTime?: number and
debounceEventsGuarantee?: boolean global options (also customizable per service).

API Name Change.

The createVueClient utility has been renamed to createPiniaClient. The VueService class has been renamed to PiniaService.

// src/feathers.ts
import { createPiniaClient } from 'feathers-pinia'
import { pinia } from './plugins/pinia'

const feathersClient = {} // See the Feathers Client install/setup pages
const api = createPiniaClient(feathersClient, { 
  pinia, 
  idField: '_id',
  // optional
  ssr: false,
  whitelist: [],
  paramsForServer: [],
  skipGetIfExists: true,
  customSiftOperators: {},
  services: {},
})

All of that effort to setup a Version 2.0 app is now a thing of the past. In 3.0, we've identified the best patterns from the giant 2.0 refactor and made all of the features implicit, with the ability to customize where needed. The result is a work of art. Here's all it takes to configure all services with a global configuration:

// src/feathers.ts
import { createVueClient } from 'feathers-pinia'
import { pinia } from './plugins/pinia'

const feathersClient = {} // See the Feathers Client install/setup pages
const api = createVueClient(feathersClient, { pinia, idField: '_id' })

And with that you get a wrapped Feathers Client with all of the Feathers Interface methods plus all of the API and local data-related store methods. Manually wrangling stores and Models is no longer required or even an option. Data modeling still runs the show, under the hood, and all data is turned into FeathersInstance instances, by default. If you want to extend that functionality, you can use the services option of the global config and provide a setupInstance method, like this:

// src/feathers.ts
import { createVueClient } from 'feathers-pinia'
import { pinia } from './plugins/pinia'

const feathersClient = {} // See the Feathers Client install/setup pages
const api = createVueClient(feathersClient, { 
  pinia, 
  idField: '_id',
  services: {
    users: {
      setupInstance(data: FeathersInstance<Users>) {
        return useInstanceDefaults(data, { name: '' })
      },
    },
  },
})

And with the above code in place you have a default name property on every instance. You can still setup relationships, etc.

Create a Store

Here's all it takes to create a store and fetch some data:

api.service('users').find({ query: {} })

That's it. Just by using the service, a Pinia store is created for you and is filled with whatever data comes back from the client.

The rest of the goodies you can find in the new docs at https://v3.feathers-pinia.pages.dev.

Model.useGet and Model.useGetOnce no longer require a params argument to be provided as the second arg.

const Task = useTaskModel()

Task.useGet(1)

The following utils now execute properly:

• Model.useFind
• Model.useGet
• Model.useGetOnce

Full Changelog: https://github.com/marshallswain/feathers-pinia/compare/v2.0.0-pre.12...v2.0.0-pre.13

Auto-Imports with Vite, Webpack, Rollup, etc.

You don't have to use Nuxt to get first-rate Auto-Imports with Feathers-Pinia, anymore. All of the Auto-Import goodies for Nuxt are now fully supported in Vite, Webpack, Rollup, and apps built with other bundlers. Feathers-Pinia now exports a new feathersPiniaAutoImport module, which can be passed directly to unplugin-auto-import in a config file. See the new Auto-Imports page for more details.

This release also adds documentation for the following:

• Auto-Imports
• A new Vite setup guide, using the new Auto-Imports API
• Additional docs for OFetch and using it for SSR/SSG
• Better communication for using Feathers Dove Types

And new topics in the Common Patterns page:

• Feathers Client
  • Manually setup a Feathers Client (without createClient)
  • Setup Multiple Feathers Clients
  • SSG-compatible localStorage
  • Server-Compatible Fetch
• Avoid npm install errors
• Global Configuration

Full Changelog: https://github.com/marshallswain/feathers-pinia/compare/v2.0.0-pre.11...v2.0.0-pre.12

feat: params.clones queries store data as clones

You can now make a query with params.clones set to true to return each record as a clone of itself. If there’s already an existing clone in the store, it will be reused. If the clone is outdated, call clone.reset() to get the latest data.

See examples in the docs: https://v2.feathers-pinia.pages.dev/guide/querying-data.html#params-clones

Full Changelog: https://github.com/marshallswain/feathers-pinia/compare/v2.0.0-pre.10...v2.0.0-pre.11

Fixes https://github.com/marshallswain/feathers-pinia/issues/72. The useFind utility was caching params internally when params of different names were applied to the query. (like changing from { name: 'Marshall' } to { age: 21 })

🙏 Special thanks to @emmanuelgeoffray. The updateParamsExcludePage function was updated according to his recommendation.

Full Changelog: https://github.com/marshallswain/feathers-pinia/compare/v2.0.0-pre.9...v2.0.0-pre.10

Related to issue #93, this fixes a bug where you can't handle the error when calling clone.save() because it gets swallowed. Since this is handled in hooks, now, the hook rethrows the error after rolling back the eager updates.

Full Changelog: https://github.com/marshallswain/feathers-pinia/compare/v2.0.0-pre.8...v2.0.0-pre.9

The following APIs have been removed:

• setupFeathersPinia
• defineStore
• BaseModel
• Find
• useFindClass
• Get
• useGetClass
• old 'service-store/types'
• models (global models)
• clients (global clients)
• registerClient

Not yet removed:

• useFindWatched
• useGetWatched

Full Changelog: https://github.com/marshallswain/feathers-pinia/compare/v2.0.0-pre.7...v2.0.0-pre.8

This release gets rid of the defineAuthStore utility, which is replaced by the more-flexible useAuth utility. We also now have unit tests for useAuth (we only had integration testing, before).

Full Changelog: https://github.com/marshallswain/feathers-pinia/compare/v2.0.0-pre.6...v2.0.0-pre.7

useAuth was built for the BaseModel class, which had a getAnyId instance method. The new Model Function instances are cleaner and don't need the getAnyid functions, so useAuth now properly reads the __idField to handle the user after successful auth.

Happy New Year, everyone! We have a new year and a new gift for 2023 in the form of the Feathers-Pinia Nuxt module!

This release adds compatibility for the nuxt-feathers-pinia package. Read the documentation to find out how it makes life easier when using Nuxt 3.