Vue3 Webcomponents share Pinia Store

[m1rm]

During work I came across the need to embed a web component built with Vue3 and Vue's defineCustomElement function into another website more than one time.

The web component is rather complex with one "root level" Vue file that uses several other normal Vue components, so I made a simple reproducer that showcases my finding: https://github.com/m1rm/vue3-webcomponent-reproducer/tree/main

Although it is made clear in the pinia documentation, that pinia stores are global (that's why we use/want/need stores), I did not expect the web components to share state.

The only way I found (apart from encapsulating the web component in an iFrame) to separate the stores between web components would be to pass a unique ID to the store upon instance creation of the web component.

--> Edit: I added a provide/inject example in the reproducer and I think that would work, too.

For the real-world use case of my company that would mean to also pass this unique ID generated in the "root level" Vue-file down to all child components via a prop (a technique called "prop drilling"). But this is against the intention/idea of using a store and we then could not use a store at all (with all the downs coming from not using one regarding shared state within the web component). Also, using Vue's provide/inject is a document Vue-way but I would rather expect Vue to handle scoping everything to the web component for me.

I wonder if
a) the behavior of pinia is intended for surpassing the borders of web components
b) there is any better solution out there (preferably without the use of internal APIs like showcased here https://rimdev.io/vue-3-custom-elements)

Related discussions: #840 -> leaves out the web component part as far as I understood

[akuehnis]

I run into the same problem. I hve tried to avoid Pinia and use a standard Vue reactive as described here:

https://vuejs.org/guide/scaling-up/state-management.html#simple-state-management-with-reactivity-api

Unfortunately, the problem is exaxtely the same: Multiple customElements on the same page share the same state.

[akuehnis]

A solutions using random store names and provide/inject :

// main.js
import {defineCustomElement} from 'vue'
import App from './App.vue'
import styles_lic from "./styles.lic.css?raw"
App.styles = [styles_lic];
const TheElement = defineCustomElement(App);
customElements.define('my-superelement', TheElement);

// plugins/Store.js
import {defineStore} from "pinia"

// holds store instances
let store_list = {}

// definition of the store
const storeDefintion {
    state: () => ({
    }),
    getters: {   
    },
    actions: {
    }
    
})

// export a function to get the store by name
export const useOwnStore = (storeName) => {
    if (typeof(store_list[storeName]) == 'undefined'){
       // create new store only if it does not exist yet
        const store = defineStore(storeName, {...storeDefintion});
        store_list[storeName] = store();
    }
    return store_list[storeName];
}
export default useOwnStore;

// App.vue
<script setup >
  import { provide } from "vue"
  import {createPinia, setActivePinia} from "pinia"
  import useOwnStore from "@/plugins/Store"
  setActivePinia(createPinia());
  let randamStoreName = 'store'+ Math.floor(Math.random() * 1000);
  provide('$storeName', randamStoreName); // provides the name for other components
  const Store = useOwnStore(randamStoreName);
  
 ...
</script>

// AnyComponent.vue
<script setup >
  import { inject} from "vue"
  import useOwnStore  from "@/plugins/Store"
  let ownStorename = inject('$storeName'); // is provided by App.vue
  const Store = useOwnStore(ownStorename);
 ...
</script>

[kevinramharak]

Pinia uses an active instance, that is injected into the Vue application. If your components are part of the same vue app and use useStore in the same context, then they will share state. This is exactly what pinia is made for.
Either you are looking to create multiple instances of a vue app, where each app will have its own pinia instance, or you are looking for a solution that is not a global store, but a scoped store where you provide the boundaries of the scope. There is nothing built-in for this, so you will have to find a library or build it yourself.

Also ask yourself, do you really need pinia for this? If you want a 'store', you could just create a reactive object and expose some methods to modify this state in a composable and return that.
And to provide the scoping you want, you can use provide/inject as you did in your example.

Initially, when I learned the new Vue active instance design, I ran into similar issues because it requires you to be aware that code behaves based on whatever code is considered 'active' at that moment.
Having pinia be designed to drop the reusability of stores is disappointing as it does not provide an alternative.

So my answers to your questions would be:

a) the behavior of pinia is intended for surpassing the borders of web components

Yes this is intended behaviour. Because the web component instances are explicitly opting into the global shared state by using a globally shared store. There is no border between web components, they are just components in the same app instance.

b) there is any better solution out there (preferably without the use of internal APIs like showcased here https://rimdev.io/vue-3-custom-elements)

The article seems to be using a hack to accomplish the idea of a reusable store, but really its just using the wrong tool for the job. If this is still an active problem let me know, and I'll try and write out an example of using a composable that implements your requirements.

[akuehnis]

@kevinramharak

Very interesting information.

Until today I thought that each Custom Element creates and runs it's own Vue application and as such would have it's own scope - even if they have the same name (<my-superelement><my-superelement> in my example).

Reading your information makes me wonder if this assumption is completely wrong. What is your opinion about this?

[kevinramharak]

Reading through the docs I don't see anything that indicates it would be a standalone app.
I do wonder if they become separate applications when passing the return value of defineCustomElement to CustomElements.define.

In the provided example repository it explicitly uses createApp:

const TestButtonElement = defineCustomElement(TestButton)
customElements.define('test-button', TestButtonElement)

const TestButtonElement2 = defineCustomElement(TestButton2)
customElements.define('test-two', TestButtonElement2)

const separateStoresTestButtonElement = defineCustomElement(SeparateStoresTestButton)
customElements.define('test-unique', separateStoresTestButtonElement)

const TestButtonProvideInjectElement = defineCustomElement(TestButtonProvideInject)
customElements.define('test-provideinject', TestButtonProvideInjectElement)

const piniata = createPinia()
createApp(App).use(piniata).mount('#app')

With your example however, I would expect each instance to create its own app instance, and you should not have to use a unique id, as you seem to create a pinia instance for each app.

[kevinramharak]

@akuehnis Using a quick mockup in stackblitz: https://stackblitz.com/edit/vue-da9jbp?file=src%2Fcomponents%2FCustomElement.vue

It seems like each component is its own application, or at least with createPinia and setActivePinia each component uses their own store instance, even if they reuse the same store definition.

Edit:
I added the usage of getCurrentInstance to retrieve the app instance. Both state their appContext.app is null, which probably means the components themselves are the root component / app. So as far as I can tell, each custom element bootstrapped with customElements.define is its own app instance.

[akuehnis]

Nice example!
And you are right. In a small test application (using defineCustomElement and App.vue as in my previous example) I could prove today that each App is independent and each Pinia Store is independent, too.
Why I did observe the complete opposite last week - I have no idea.