exposing custom options and injecting new actions in TS

[theoephraim]

I'm trying to port over some tools I had previous built with vuex (without Typescript) over to pinia. Specifically, this tool helps simplify all the boilerplate involved with making API requests and tracking the state of those requests in the store.

Basically I define a set of "api actions" which are functions that take in a payload and returns a description of how to make the API request and what to do if successful. The tooling then handles marking the making the request, all the error handling, and tracking the status (pending, success, error, etc) along the way.

There are obviously many ways to do this, but my first inclination was to use a plugin to add a new "option" for my special api actions. For example:

export const useAuthStore = defineStore({
   ...,
  apiActions: { // <- my new custom option
    login(payload: { username: string, email: string)) {
      return { // returns a description of how to make the request
        method: 'POST',
        url: '/login',
        payload,
        onSuccess(response) { this.$patch({ userId: response.userId, ... }); }
    }
...

Now to actually trigger these actions, I see two options

• 1. inject these new special actions into the store as regular actions/methods
• 2. inject a single new method like triggerApiAction(actionName, payload)

I don't think there will be any problems on the actual functionality side, however I'm having issues getting the TS types to work. As far as I understand, I need access to the data passed to my new custom option in the type generics the same way that the state, getters, and actions are exposed.

For option 1, I would try to inject new methods for all of the keys defined under apiActions

For option 2, I would try to add typing to the parameters passed to triggerApiAction - first to restrict the action name to one of those defined, and then ideally to restrict the payload somehow to match the one specified by the action name.

Additionally, I'd want to use those "action names" again in typing the parameter of a "getRequestStatus" function, which uses that same request name. In this regard, using regular strings may actually be helpful, so I dont have to define and import an extra enum all over the place.

I don't have much experience with these more advanced typescript definitions, so unclear if it's possible. Also open to other suggestions of how to accomplish this, although I'm trying to avoid a setup like the debounce example in the docs, as I'd like to keep the full definition of the api request action all together.

Thanks!

[posva]

Do you have a partially working example on codesandbox or GitHub?

[theoephraim]

put up some code here - https://codesandbox.io/s/pinia-example-forked-iv9d5?file=/src/pinia-plugin.ts
It's not complete, but it should hopefully help illustrate what I'm trying to do. Thanks!!

[theoephraim]

It also seems that while a plugin can augment the store, it is only able to add arbitrary properties to it. Ideally it could specifically add items to the state/getters/actions. This would be necessary so that some new state added by a plugin is available when calling this.$patch. I assume there are probably many other cases where extra behaviour/transformations is applied to the state/getters/actions as well.

[posva]

That sounds a lot like mixins for a store. I would be interested in seeing use cases as I don't think it's a good pattern. That being said, a plugin can add anything to a store and since stores are wrapped with reactive, the data will be reactive. You wouldn't be able to call $patch but you would be able to do store.mynewData = ...

[posva]

This is an example of extending with custom types: https://codesandbox.io/s/pinia-example-forked-cuj8g?file=/src/pinia-plugin.ts:1237-1785 check the store.ts file for usage and you will see things are correctly typed

[theoephraim]

Thanks so much for taking some time to play with it - it is much appreciated!

In this case, I really would hope that the plugin code stays totally isolated and doesn't know anything about the specific actions defined in each store. I may be able to get away with each each store augmenting some global interface to add its actions, but that is feeling pretty awkward. The other goal is really to remove any duplicate definitions if at all possible - ie not having to list the actions or types in multiple places.

I'm going to dig into the pinia code a bit and see what I can figure out, although there is some pretty gnarly typescript stuff going on in there, so we'll see how far I get.

I'd be happy to dive into the use case a bit more with you as well if you have time. I've used this api request tooling/pattern on a few projects and I really think it's super useful and can benefit the community if I can get it right. I'd also love to help contribute to this tool's (and future vuex) development in any way I can.

Cheers and thanks for your work on pushing vue's state management tooling forward :)

[posva]

In this case, I really would hope that the plugin code stays totally isolated and doesn't know anything about the specific actions defined in each store.

But in that case you won't be able to have the type safety I showed you. You can still augment a global interface as you said. That would be the ApiActions interface.

ie not having to list the actions or types in multiple places.

That's already achieved 😅 . You will need the ApiActions type, but that's pretty common in TS land

I think you can share your advancement here and I will try to read and answer.

Cheers and thanks for your work on pushing vue's state management tooling forward :)

Thanks! I'm glad you are enjoying it