Pinia Plugins: Finding the Right Approach for Extending Stores

[mailok]

The fundamental problem I see with Pinia plugins is that the type definitions created for the plugins affect all the stores in your application 😱. This means that you might have a store called useXXXX, and when a random developer in the company has to work on the code related to that store, they might see that the useXXXX store has functions that don't exist in that store. Furthermore, it doesn't make sense for a store of that type to have those functions, but the developer sees them due to TypeScript's autocomplete.

This becomes a significant problem when there are multiple teams working on the same source code within a company 😩.

Therefore, I wonder what the appropriate approach would be to create a plugin without encountering these frustrating disadvantages. So far, considering these limitations and others, such as the inability to observe actions added by plugins through store.$onAction, I'm leaning towards the conclusion that plugins are only suitable for the following use cases:

• Global Error Handling
• State Persistence
• Analytics
• Global Middlewares

Apart from these use cases, using plugins to extend stores would require organizational actions within the company's teams to avoid the issues with type definitions.

I wonder if there has been any consideration given to rethinking the entire approach to Pinia plugins, allowing them to be defined directly in the store creation definition 🤔

[mailok]

This concern was already answered in Discord, and the answer was to use composables for this way of extending the Store.