Should I put business logic in stores?

[inhibitions]

I'm seeing 2 possible approaches here:

1. I create composables (or services?) that contain the business logic and serve as a bridge between the components & the stores.
   1. Stores contain 0 business logic
   2. Stores simply hold the data
2. Actions & getters in the stores contain the business logic as well (that would otherwise have been inside composables/services)

I'm using Nuxt 3 by the way, if that's a factor.

Suppose I have a collection of To Do tasks that get stored inside useToDoStore.

When I add a new To Do to the store, let's say there's a little bit of business logic (for simplicity, let's say we're not communicating with an API for now):

• Check if the userId of the To Do author exists
• Generate an ID for the To Do based on a particular format

Let's say there are multiple places in the app where we can add a new To Do.

I can see decoupling the business logic from the Pinia store as a merit if I decide to use a different state management library in the future, I guess? But at the same time the flow of data is easier to follow if the business logic is also kept inside the Pinia store. Is there perhaps a longer explanation for why the docs say that Actions are the perfect place to define business logic?

[angelhdzmultimedia]

I see Pinia stores as a Reactive Service.

Let's remove Pinia from the equation for a sec, how would we manage the state out of Vue components?

With the reactive() object and using an instance of a class (the service):

class AuthenticationService {
  public isAuthenticated: boolean = false
  public user: AuthenticatedUser | null = null
  
  public login(email: string, password: string): Promise<void> {
     // API call
     this.isAuthenticated = true
     this.user = data.value
  }
}

const authenticationService = new AuthenticationService()
export const useAuthenticationService = () => reactive(authenticationService)

So, translating that logic into Pinia, the Pinia store actions represent the methods of a service class...

For me, using pinia stores as services have worked good enough,

But of course, you can always have a services directory with services classes, and instantiate/call them from the pinia stores.

I use mostly NestJS on the backend (sometimes use Nuxt as backend as well), and there we have modules, controllers, services.

From ChatGPT:

In Vue.js, the choice between using Pinia stores for business logic or defining separate service classes largely depends on the complexity and organization of your application. Both approaches have their advantages and can be used effectively, so it's essential to consider your project's specific requirements and structure.

Using Pinia Stores for Business Logic:

Pinia is a state management library that can be used to centralize and manage your application's state, including business logic.
You can define actions and getters in Pinia stores to encapsulate and manage your business logic alongside your state.
This approach is suitable for smaller to moderately complex applications where you want to keep everything related to your state and business logic in one place.
It simplifies the code organization by having a single source of truth for both state and business logic.
Example:

// Pinia Store
import { defineStore } from 'pinia';

export const useCounterStore = defineStore('counter', {
  state: () => ({
    count: 0,
  }),
  actions: {
    increment() {
      this.count++;
    },
  },
});

Using Separate Service Classes:

In larger and more complex applications, it may be beneficial to separate your business logic from your Pinia stores.
You can create a services directory where you define service classes responsible for various tasks, such as API calls, data processing, or other non-state-related logic.
These service classes can then be imported and used within your Pinia store actions or components.
This approach promotes a cleaner separation of concerns and allows for easier testing of your business logic.
Example:

// Service Class
export class CounterService {
  incrementCounter(count) {
    // Perform some business logic
    return count + 1;
  }
}

// Pinia Store
import { defineStore } from 'pinia';
import { CounterService } from '@/services/counterService';

export const useCounterStore = defineStore('counter', {
  state: () => ({
    count: 0,
  }),
  actions: {
    async increment() {
      const service = new CounterService();
      this.count = await service.incrementCounter(this.count);
    },
  },
});

The choice between these two approaches depends on factors like the size and complexity of your application, code maintainability, and personal preferences. Smaller projects might benefit from using Pinia stores for both state and business logic, while larger projects may benefit from the separation of concerns provided by service classes. Ultimately, it's essential to strike a balance that works best for your specific use case.