Why are more and more developers using the Store as a "Class"??

[rezelute]

I have been noticing in all the Frontend applications that more developers are using the Vue store as a Class based approach for example:

export const useStudiesStore = defineStore("studies", {
   state: () => ({ consented: false, loading: false, studies: [] as Study[], enrolCount: 0 }),
   actions: {
      consent() {
         this.consented = true;
      },
      async populateStudies() {
         try {
            ... // fetch studies from API
         } catch (error) {
            console.log(error);
         }
      },
      async toggleEnrolment(studyId: string, reason?: string) {
         try {
            ... // enrol/unenrol from study
         } catch (error) {
            console.log(error);
         }
      },
   },
});

From everything that I have been taught in the past, a Store in Vue should only be used if it will genuinly be shared between components (likely across different pages such as a notification badge). However many developers are using the store as a "Class" even knowingly that they wont be using it to be shared across components.

Can someone shed some light on why this tend is appearing?

[marcosgomesneto]

Based on your code, it seems that there is still potential for reusing states and actions. I may not have the complete context of this project, but it appears to make sense to use state in this scenario. You can retrieve 'studies' from any component you wish to read, even if there isn't another component using it initially.

Additionally, I wouldn't precisely characterize the defineState code as a Class, but that is merely a matter of nomenclature.

[rezelute]

"Reusing states and actions" - Wouldn't what you described be a composable rather than a Vue Store? Lets say for example we have a studies page which is calling the studies list and no other page in the near future would use this functionality, would you still create a Store with states and actions?

[marcosgomesneto]

@rezelute

Composite Components

Composite components enable the encapsulation and reuse of UI logic. They prove beneficial when UI elements are utilized in various locations. This functionality leverages Vue's composition API to encapsulate and reuse stateful logic. It utilizes Vue's states and reactivity but isn't designed to share state; instead, its purpose is to provide reusable logic.

State Managers:

A state manager, such as Pinia or Vuex, is employed to handle the state of the application or pages. It becomes valuable when you have data that needs to be accessed by various components (e.g., components in different parts of the component tree). State managers are primarily about managing and sharing data and state, facilitating communication between components.

Your Project

In your example, the "studies" state seems to be a dataset that can be read by other components. When referring to "other components," these could be components on the same page, not necessarily limited to different pages. If you have a page that displays all "studies," and within that page, there is a component for searching "studies," that particular component needs to access this state from the store.

It's important to note that a store doesn't necessarily have to be shared across the entire application. You can have a store dedicated to a specific page that contains various components like "SideBar," "Search," "List," "Topbar," and so on.

Let's consider a scenario where 'studies' are exclusively used by just one component, and there's no plan for any other component to use it in the future. Wouldn't you agree that employing a store to manage this state, even if it's not reusable, makes it more organized and testable than leaving it isolated within the component? This is especially true because this state is fueled by data coming from an API, and I believe this is the point you wanted to emphasize. For a small application, this would be a good practice. However, in the case of larger applications, I typically adopt the Domain-Driven Design (DDD) methodology to organize into more intricate layers such as domains, data, repositories, etc.

[rezelute]

@marcosgomesneto

You said some very interesting things there 👍.

"Wouldn't you agree that employing a store to manage this state, even if it's not reusable, makes it more organized and testable than leaving it isolated within the component? "
Yes I do agree, it does make the code more organised however its going slightly against what Vue is advising on when to use the Store. So for example in Studies page, I would just pass down the props as long as you dont end up in prop drilling too much.

You also lead into exactly where I was going with my approaches. I would personally do the following which I think matches better with Vue recommendations (please let me know if you think im wrong):

• Have an API service layer
• Have a Class that interacts with the API layer for example

export class StudiesStore {
    constructor() {
        this.consented = false;
        this.loading = false;
       ...
    }

    consent() {
        this.consented = true;
    }

    async populateStudies() {
        try {
            // fetch studies from API
            // call endpoints from the Studies API layer here
        } catch (error) {
            console.error(error);
        }
    }

    async toggleEnrolment(studyId, reason) {
        try {
            // enrol/unenrol from study
            // call endpoints from the Studies API layer here
        } catch (error) {
            console.error(error);
        }
    }
}

• In the Studies page component, have the states that you need knowing that you dont need to share the Store across too many components.

In my approach, you wouldnt use the Store unnessarily and it solves the code being organised and split into relevant places.

Let me know what you think.

[marcosgomesneto]

I fully agree with your observation. I prefer organizing the code into a dedicated layer, using classes or functional programming. For more organized and scalable applications, I strongly recommend relying on multiple layers rather than solely depending on a store. Reserve the use of the store exclusively for its primary function, which is to facilitate state sharing among distinct components within the application structure.

If anyone else has a different opinion, I would be glad to hear more about it.

[rezelute]

Awesome thank you for your opinions and thoughts 🙏