Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting Object Reactivity Problem #14

Open
Mootook opened this issue Dec 18, 2020 · 5 comments
Open

Setting Object Reactivity Problem #14

Mootook opened this issue Dec 18, 2020 · 5 comments
Labels

Comments

@Mootook
Copy link

Mootook commented Dec 18, 2020

It seems like object-nested values are not considered reactive. Wondering if this is a specific choice (if so, what're the suggested workarounds). Class properties work fine, but some of my classes have objects as properties which get set from null to some object structure after an api call. That final set does not seem to trigger a render update.

obj = null

const response = someAPI()

obj = response // does not trigger a rerender on dependent components

I've got a codesandbox to illustrate my point: https://codesandbox.io/s/vue-store-example-nested-key-reactivity-4v2s0?file=/src/components/HelloWorld.vue. From my understanding, Vue2 did have some reactivity caveats with objects. Wondering if those are to stay (my project is in vue3)

It's specifically related to add or deleting keys, as an object with the keys set already to dummy values seems to update.

@davestewart
Copy link
Owner

davestewart commented Dec 18, 2020

Hey Alex,

TBH I'm not really using Vue 3 yet.

I suspect it is because you are replacing the object, that is the issue. But I don't know.

It might be worth trying this in Vue 3 without and Vue Class Store to see what the behaviour is.

It would be good to know why this is, so if it causes an issue for VCS I can recode things, or provide a workaround, such as helper functions, or something.

@Mootook
Copy link
Author

Mootook commented Dec 18, 2020

Ah, yes your hunch is correct. So long as it's a modification on that original object, it seems fine.

obj = {}
obj.value = 1 // works

obj = {}
obj = { value: 1 } // does not work

I suppose the best way to circumvent this it just to write a setter for class member variables that are objects. A helper function on that might involve a proxy (based on a cursory google), which could be overkill.

Thanks!

@nebaughman
Copy link

This is not strictly a Vue 3 issue. I experience the same issue in Vue 2. That is, setting a new object to a @VueStore class property does not trigger reactivity.

For arrays I've used this workaround:

@VueStore
class Store {
  someArray: Item[] = []
  someMethod(newValues: Item[]) {
    // this.someArray = newValues // does not work - no reactivity!
    this.someArray.splice(0, this.someArray.length, ...newValues)
  }
}

For replacing object properties, do we need to use Vue.set(this, 'theProperty', newObj)?

Thanks for any advice!

@nebaughman
Copy link

Vue 2.6.12

I think this is related: The watcher syntax "on:someProperty"() {...} does not trigger when a property (object or primitive) of a @VueStore class is set. Vue.set(this, 'theProperty', newObj) does not make any difference.

Grain of salt: I'm having trouble reproducing the bug in an isolated (vue-cli) test project, but in a larger project, setting properties (objects or primitives) in a @VueStore class does not trigger reactivity.

For example:

@VueStore
class SomeStore {
  public isReady: boolean = false

  // this does not trigger when isReady changes... in some cases??
  private "on:isReady"() { ... }
}

Workaround:

@VueStore
class SomeStore {
  private readonly state = { isReady: false }
  public get isReady() { return this.state.isReady }

  setReady() { this.state.isReady = true } // or setter syntax

  private "on:state.isReady"() { ... } // this works
  private "on:isReady"() { ... } // this works, too
}

@nebaughman
Copy link

The issues I reported above (properties not reacting when set) may have been addressed by commit 0233ecc. Pulling the latest of the DFStudio:direct-injection branch (and using yarn link locally) seems to have fixed the problem I was experiencing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants