Feature request: lightweight, non-DOM Vue class for services

[davestewart]

Overview

TL;DR This is related to the Store pattern, but is not the Store pattern per-se

So at one end of the data-modelling spectrum we have components and reactive properties. In complex apps, you can have a lot of "extra" functionality on parent components to do things that are "related" to the component's job.

At the other end, we have Vuex, with state, getters, and async actions. If not careful, you can find yourself with a lot of "preparatory" or "related" code in the store.

However, I find myself needing something to be shared across various components, but without the overhead of Vuex (and not needing to be centralised) and and simple, reusable service classes generally fit the bill.

If the service is just dumb (let's say a loader) I can get away with a simple class. However, if the service requires state, or it looks advantageous to move state from several components, say, to the service, then using a new Vue() is normally the best way.

Using a Vue instance is a great way to:

• declare data and methods as per the rest of your app
• use computed properties for free
• have watchers for free
• gain access to the $store

However, they also come with a bunch of machinery (probably most) that's just not needed:

• anything DOM related (events, props, refs, parent, children, etc)
• anything visual, such as templates
• probably more I can't think of right now

It would be really nice to be able to break out the simple reactiveness of a Vue component into some kind of precursor that could be used independently of something visual.

What problem does this feature solve?

• Provides a simpler yet still Vue-centric alternative to new Vue()
• Silos the reactivity from DOM / component overhead
• Allows components and to store to be cleaned up
• Makes wiring and debugging simpler

What does the proposed API look like?

// service
const service = new Store({ data, methods })
export service

// component
import Foo from 'services/FooService'
import Bar from 'services/BarService'

export default {
  computed: {
    ...foo: Foo.$options.computed, // or maybe even Foo.$computed
    bar: Bar.value,
    baz () {
      return this.baz.replace(/\W+/g, '-')
    },
  }
}

Not sure yet how much of Vue's API would be included (events as well?)

The Vue class itself would then mix-in or extend the Store class.

[posva]

You don't need to wait for us to build it 😄
Services are out of Vue scope and not everybody like them, we think Vuex goes well with Vue but you're free to use something else precisely because it doesn't come baked right into Vue.

We do offer alternatives to Vuex because we know it doesn't fit everybody's mindset. Other have created different solutions you can use as well (Google state vue and similar)

At the end, what you want to do is pretty much doable already with just new Vue() because you don't need to provide an el nor template (or render) function to use a Vue instance for other purposes (a store, an event bus). You may have a small memory overhead compared to using a barebones solution but that overhead is comparable to another component in your page and therefore very low: http://jsfiddle.net/posva/2hL2yjqs/
You can even create custom properties for your store and make a global mixin that merges those properties in the beforeCreate hook

[davestewart]

Hey @posva,

Thanks for reading, and the reply.

You're certainly right that this is "doable right now" and I thought this would get short shrift!

It wasn't really about the memory to be honest, more about the API and general complexity.

I got a weird edge case recently with Vue store / services and essentially broke my app for about 6 hours that severely dented my confidence in Vue stores, which I discovered I wasn't alone in:

• https://forum.vuejs.org/t/accessing-this-store-on-new-vue-event-bus/23080/8
• Cannot access Vuex $store inside Modal component buefy/buefy#55
• Uncaught TypeError: Cannot read property 'getters' of undefined vuex#264

Maybe those issues could be solved by themselves, but it struck me that just breaking out the reactivity system would be useful in itself.

On a side note, I've recently made a service with Vuex registerModule() and it was pretty cool to see data being programatically being added to the store! Not right for most situations, but cool.