Ability to manually trigger plugin action subscriptions within a setup store

[Travis Wilson]

What problem is this solving

• Currently, I have a setup store with a number of actions (let's call the functions A, B and C).
• C acts as a higher order function that calls A and B, among other things. This is to keep logic DRY and testable.
• I also have a plugin attached to Pinia subscribing to the actions A and B.

When calling C(), the store is not triggering subscriptions for A and B, causing the plugin to not receive updates when those actions are fired.

Proposed solution

I propose that we be given an ability to manually trigger action subscriptions from within a store to counter this behavior.

An alternative is to simply have actions in a setup store trigger their $onAction subscriptions, whether called internally or externally.

Describe alternatives you've considered

To circumvent this, I would need to double-up my code, or create an additional subscription in the plugin that doubles up the logic in the plugin. This feels like an anti-pattern that could better be solved if the dedicated subscriptions would simply trigger when called, internally or externally.

[Eduardo San Martin Morote]

This is a technical limitation. To fix it, it would require wrapping functions within setup stores with some internal action(() => {...}), which adds a boilerplate but also doesn't work with composables returning functions. Even if it could be automatically added with a vite plugin, it wouldn't work in many scenarios.

I propose that we be given an ability to manually trigger action subscriptions from within a store to counter this behavior.

This would just be a hacky workaround...

I'm looking for other ideas and feedback regarding the action() wrapper. It might be a useful addition for future major versions. So far, it seems a bit too much to just have it for plugins