pineapple/cow

Pinia/Vuex as well as Redux are designed to be a "single source of truth", you can have one or more stores to hold application data that can be obtained from anywhere.

Pinia stores look like this:

export let useProductsStore = defineStore('products', () => {
    let data = ref(products);

    function getList (params) {
        return someSearchStuffForProducts(params);
    }

    return {data, getList};
});

can then be used as:

let productsStore = useProductsStore();
console.log(data, data.value);
productsStore.getList(params);

We can create multiple stores:

let usersStore     = useUsersStore();
let productsStore  = useProductsStore();
let basketStore    = useBasketStore();
let favoritesStore = useFavoritesStore();

Stores can reference each other:

export let useUsersStore = defineStore('users', () => {
    let productsStore = useProductsStore();
}

export let useBasketsStore = defineStore('basket', () => {
    let productsStore = useProductsStore();
}

//Et cetera

Finally, Pinia/Vuex are tools that provide the ability to retrieve and manipulate data stored in state.

Manager/Service Class

But there is another mature approach: the manager/service class.

The previous example can be rewritten as:

//Define the "single source of truth"
let store = {
    products:      { /* ... */},
    currentUser:   { /* ... */},
    userBasket:    { /* ... */},
    userFavorites: { /* ... */},
};

//Here goes manager classes
class ProductsManager {
    constructor (params) {
        this.state = params.state;
        //...
    }

    getList (params) {
        return someSearchStuffForProducts(params);
    }
}

class UsersManager {
    constructor (params) {
        this.state = params.state;
        //Products manager is injected as a dependency
        this.productsManager = params.productsManager;
        //...
    }
}

class BasketManager {
    constructor (params) {
        this.state = params.state;
        //Products manager is injected as a dependency
        this.productsManager = params.productsManager;
        //...
    }
}

//Some config/initialization script
export let DIC = {}; //Container for manager instances
DIC.productsManager = new ProductsManager({state: store.products});
DIC.usersManager = new usersManager({
    state:           store.currentUser,
    productsManager: DIC.productsManager,
});
DIC.basketManager = new BasketManager({
    state:           store.userBasket,
    productsManager: DIC.productsManager,
});

//Usage
import {DIC} from './config';
DIC.productsManager.getList();
DIC.basketManager.add(someProductId);
DIC.basketManager.changeCount(someProductId, 3);

All of this can be easily typed in TypeScript without the need for extra wrappers, ref() etc.

discuss

From what I can tell, Pinia looks like "reinventing the wheel": writing the same functionality in a clumsy way.

Additionally, it does not provide dependency injection: you cannot initialize stores in the configuration and inject one store exactly into another, you have to pass useProductsStore() etc.

Inheritance or any other OOP stuff is also not possible.

Pinia even promotes circular dependencies, resulting in spaghetti code with poor maintainability

So, after all, why should one prefer Pinia/Vuex over the tried and tested clean OOP approach with manager classes? I've spent dozens of hours writing a tutorial project of my own invention using Pinia as the "next recommended state management for Vue", and now I'm tempted to rewrite everything into manager classes because I find Pinia clunky and rich . I just remembered that a few years ago I was writing another test project - using Vue2 - and at that time I used the manager class - and everything went smoothly. Did I overlook something? Will there be a problem if I give up Pinia?