Private scope for non-reactive data and methods

[ardoramor]

Some data that is being kept track of by a component does not need to be made reactive. Currently, there is no one place to organize private data like that. Values stores in data, even if prefixed with underscore (e.g., _privateStuff), get methods added for every key of the object. I would like a dedicated space designated by Vue for private data and functions that will not be made reactive. I realize that I even now can create something like private or _private but there is no guarantee that it will not clash with Vue's future development.

It would be great to have a $private namespace allocated. It can be populated from private key of the component configuration object:

{
data: function () {...},
props: {},
methods: {},
private: {
// private variables that are not made reactive and are not watched
}
}

[yyx990803]

For now the easy way to do it is just attach whatever you want in created hook, because when the hook is called Vue has already finished the observation phase:

{
  data: ...,
  created: function () {
    this.myPrivateStuff = {
      ...
    }
  }
}

Note all Vue api/internal properties start with either $ or _, so as long as your property doesn't use these two prefixes it will be totally fine.

[SuperSeb92]

Using the latest version (1.0.17), it seems properties created within the hook are still reactive after setting?

I'm doing this as a work-around:

this.privateThing = JSON.parse(JSON.stringify(this.privateThing));

[salivarick]

You can do this with created(those private props can't be track by vue), but I don't think it is reasonable that all props defined in vue data, props, methods are in one scope, and for vue 2.x if you define data with _ prefix, vue will tell you can't find this prop.

[emkman]

I am still really unclear on how to do this/best practices in vue 2. I am loading the Stripe JS client inside a component and want it accessible anywhere within the component. It doesn't need to be available globally though that would be OK if that is the best option. The following code as well as numerous variations doesn't work:

mounted() {
    $script('https://js.stripe.com/v2/', function() {
      this.stripe = Stripe('pk_test_12345');
    });
},
stripe: {},

[emkman]

I ended up getting it to work with

mounted() {
    const vue = this;
    $script('https://js.stripe.com/v3/', function() {
      vue.stripe = Stripe('pk_test_12345');
    });
},

Not sure if there is a better way though

[Glidias]

Yup, the basic principle is to set the property up later and not declare it in the initialized vue data itself. Do note that if such non-reactive data is "private' to begin with, why expose it to Vue? Why not just keep the data "privately" in the current file module you are working and rely on computed public getters to proxy into specific private data if your template requires those properties? (albeit, it might mean more boilerplate..). This is a question you've got to answer for yourself. After all, if such data is non-reactive, your template will not render reactively to those data anyway if your template references such data...which is something you must seriously consider beforehand especially if passing them as props to your components, since they aren't reactive anyway.

One approach i've been using so far (sort of like singleton/local services or lazily instatiated stuff..) is to resort to a computed property that will lazily instantiate/look-up something and store it in a nested private reference on the vue instance context if not yet found. For singletons/globals, you can simply return the value directly via a global service locator or DI-reference-container or something....

Example here: (note: ....not plain JS, but can be easily adopted in vanilla JS)
https://github.com/Glidias/haxevx/wiki/Integrating-non-reactive-data-services-class-instances,-etc.-into-Vue

[DeShadow]

@Glidias Simple example for you.
I want to create Vue.js component for Cesium (or three.js, or d3.js etc.). That's why I need to initialize <div> inside component with Cesium.Viewer to have access to this instance later in my methods or events. I don't want to make this Viewer instance reactive. Because it's low-level object of 3rd-party library. That's why I want smth like this:

import Cesium from 'cesium';

export default {
    name: 'CesiumViewer',
    data(){ return { /* some data */ }; },
    created(){ this._cesium = new Cesium.Viewer(this.$el); },
    methods: {
        drawPath(points){ 
            /* some actions with this._cesium */
       }
    }
}

That's why I need a way to store internal variable of Cesium instance. And this instance is low-level and need no to be reactive.

[CrescentFresh]

My usecase is identical to @DeShadow, only for lunrjs. I initialize the lunr index object and use it throughout the lifetime of my component, however I don't need it reactive itself.

[prograhammer]

Is there anything wrong with using this.$options to store non-reactive properties (as long as there is no future conflict with the options Vue adds globally such as name)? Looks cleaner than declaring them inside created ().

export default {
  name: 'MyDashboard',
  toolbar: 'My Dashboard',  // <-- non-reactive property

  mounted () {
    console.log(this.$options.toolbar)  // <-- use non-reactive property
  },

  data () {
    return {
      // reactive data
    }
  }
}

[LinusBorg]

No, there's nothing wrong with that really. Many plugins use those as well, i.e. vue-i18n, vue-apollo, vuefire etc.

[PierBover]

I think the bigger problem here is the lack of a clear pattern.

Doing init in created() as proposed by @yyx990803 or using using $options as proposed by @prograhammer both do the job, but neither solution is explicitly saying "these are non reactive properties of this instance".

The logic in created() is related to the component lifecycle so it's obviously waiting for something to happen. That's not really what I have in mind when simply wanting to define some non reactive instance state. Also, there is no pattern here since everyone will call these properties whatever they want.

OTOH using $options seems hackish as it exposes Vue's guts but also there is no distinction between reactive and non reactive state either. Why should $options.myString live in the same level as $options.data or $options.methods?

A better solution IMO would be to have an explicit syntax to declare non reactive component state. Personally I really like the first idea @ardoramor had of using underscores for non reactive properties in data.

[LinusBorg]

Well, I can only repeat myself in saying that I don't feel that it is useful/important enough that it's worth adding a dedicated API for this.

but neither solution is explicitly saying "these are non reactive properties of this instance".

Anything in $options is not reactive. Isn't that enough? Not everything needs a dedicated API. React takes it to the extreme where everything is a prop or local state, and there's little to nothing else

OTOH using $options seems hackish as it exposes Vue's guts but also there is no distinction between reactive and non reactive state either. Why should $options.myString live in the same level as $options.data or $options.methods?

Again, nothing in $options is reactive. They are just the options used to create the component, and since non-reactive data, in my experience, is mostly exactly that - constants, options - I actually find the place quite fitting.

We are not React and want to provide abstractions where the use case justfies the added technical debt / maintaince burden. Personally, I just don't feel like this is the case here.

A better solution IMO would be to have an explicit syntax to declare non reactive component state. Personally I really like the first idea @ardoramor had of using underscores for non reactive properties in data.

That would be breaking change, so that's a definite "no".

[PierBover]

Again, nothing in $options is reactive.

Not being reactive is the natural state of things in JavaScript. Does that justify sticking non reactive component state anywhere that is non reactive?

They are just the options used to create the component, and since non-reactive data, in my experience, is mostly exactly that - constants, options - I actually find the place quite fitting.

It's quite contradictory that you'd argue for putting component state directly in $options.

Why does reactive component state live in $options.data (alongside $options.methods etc) instead of living directly in $options?

I can only assume that data means component state or reactive component state. In either case it's only logical that non reactive state would either go inside data or inside its own property (eg: staticData) and not directly in $options.

That would be breaking change, so that's a definite "no".

It makes sense. I'm only arguing that something need to be done here.