Develop Reference

Why using toRef(props) and is it good idea to change their value in CompositionAPI?

I've seen a pattern of using props in of CompositionAPI very often,
that is use toRefs to make all entries of props ref.
I'm kind of confused by it.
For exmaple, from the Vue 3 official guide:
export default {
props: {
user: {
type: String,
required: true
}
},
setup(props) {
const { user } = toRefs(props)
//... use user's value
}
}
I have 2 questions in 2 scenearios:
when the props.user is already reactive
Its value will change if it's changed in any ancestors, so why we need to use toRefs? Doesn't it already reactive?
if it's not reactive, it's just a primitive string value
Does making it reactive means we're going to change its value?
I think making a object reactive also imply that its value is welcomed to be changed.
But all the guides and linters warn us that we'd better not to change the props value.(for not writing to the computed value or something)
If I can change the props value directly in the component, I no longer need to emit the changes to parent component everytime.
It's very convenient but I don't know whenther it is a good idea to change the props value after we're sure it becomes reactive?

Since props aren't supposed to be mutated, this is useful for a specific case that is explained in the documentation; a ref that is computed from a prop needs to be passed as an argument:
const { user } = toRefs(props)
// or
// const user = computed(() => props.user)
someFunction(user);
Where a function makes use of composition API or just needs an argument to be passed by reference rather than by value due to the way it works, e.g.:
function someFunction(val) {
setTimeout(() => {
console.log('Up-to-date value:', unref(val));
}, 1000);
}

How can I make an Ember computed property depend on all descendent properties of a variable?

I'm trying to create a computed property that I want to be reevaluated whenever any value in a deeply nested object changes. I understand that myObj.[] can be used to reevaluate computed properties whenever any object in an array changes, but I want this to be recursive.
eg I have
// should recalculate whenever myObj.x.y.z changes, or when myObj.a.b.c changes
computed('myObj', function() {
// ...
})
I don't know in advance exactly how the object is structured, and it may be arbitrarily deep.
Neither computed('myObj.[]', ...) nor computed('myObj.#each', ...) seem to work for this.
Any ideas how to do this?

In Ember it is possible to define computed properties at runtime
import { defineProperty, computed } from '#ember/object';
// define a computed property
defineProperty(myObj, 'nameOfComputed', computed('firstName', 'lastName', function() {
return this.firstName+' '+this.lastName;
}));
So taking that a step further, you could dynamically create whatever computed property key string you want at runtime (this could be in component's init() or something):
// define a computed property
let object = {
foo: 'foo',
bar: 'bar'
}
this.set('myObj', object);
let keys = Object.keys(object).map((key) => {
return `myObj.${key}`
});
defineProperty(this, 'someComputed', computed.apply(this, [...keys, function() {
// do something here
}]));
It's up to you to figure out how to properly recursively traverse your objects for all the dependent keys without creating cycles or accessing prototype keys you don't want...or to consider whether or not this is even that good of an idea. Alternatively, you could try to handle the setting of these properties in such a way that retriggers a computation (which would be more in line with DDAU). I can only speculate from what you've provided what works but it's certainly possible to do what you want. See this twiddle in action

could you try anyone computed/obeserver like below..
But try to prefer the computed.
import { observer } from '#ember/object';
import EmberObject, { computed } from '#ember/object';
partOfNameChanged1: observer('myObj','myObj.[]','myObj.#each', function() {
return 'myObj is changed by obeserver';
})
partOfNameChanged2: computed ('myObj','myObj.[]','myObj.#each', function() {
return 'myObj is changed by computed';
})
then in your handlebar/template file
{{log 'partOfNameChanged1 is occured' partOfNameChanged1}}
{{log 'partOfNameChanged2 is occured' partOfNameChanged2}}
Then you have to associate/assign this partOfNameChanged1 / partOfNameChanged2 to some where in the handlebar or to any other variable in your .js file.
As long as you have not assigned this computed/observer property partOfNameChanged1 /partOfNameChanged2 to somewhere, then you will not get it's value.

Vue data not available until JSON.stringify() is called

I'm not sure how to tackle this issue because there's quite a bit into it, and the behavior is one I've never seen before from JavaScript or from Vue.js
Of course, I will try to keep the code minimal to the most critical and pieces
I'm using vue-class-component(6.3.2), so my Vue(2.5.17) components look like classes :)
This particular component looks like so:
import GameInterface from '#/GameInterface';
class GameComponent extends Vue {
public gameInterface = GameInterface();
public mounted() {
this.gameInterface.launch();
}
}
GameInterface return an object with a launch method and other game variables.
In the game interface file to method looks something like this:
const GameInterface = function () {
const obj = {
gameState: {
players: {},
},
gameInitialized: false,
launch() => {
game = createMyGame(obj); // set gameInitialized to true
},
};
return obj;
}
export default GameInterface;
Great, it works, the object is passed onto my Phaser game :) and it is also returned by the method, meaning that Vue can now use this object.
At some point I have a getter method in my Vue class that looks like so:
get currentPlayer() {
if (!this.gameInterface.gameInitialized) return null;
if (!this.gameInterface.gameState.players[this.user.id]) {
return null;
}
return this.gameInterface.gameState.players[this.user.id];
}
And sure enough, null is returned even though the player and id is clearly there.
When I console.log this.user.id I get 4, and gameInterface.gameState.players returns an object with getters for players like so:
{
4: { ... },
5: { ... },
}
Alright, so it does not return the player even though the object and key are being passed correctly...
But I found an extremely strange way to "FIX" this issue: By adding JSON.parse(JSON.stringify(gameState)) like so
get currentPlayer() {
// ...
if (!this.gameInterface.gameState.players[this.user.id]) {
// add this line
JSON.stringify(this.gameInterface.gameState);
return null;
}
return this.gameInterface.gameState.players[this.user.id];
}
It successfully returns the current player for us... Strange no?
My guess is that when we do this, we "bump" the object, Vue notices some change because of this and updates the object correctly. Does anyone know what I'm missing here?

After working on the problem with a friend, I found the underlying issue being a JavaScript-specific one involving Vue's reactive nature.
https://v2.vuejs.org/v2/guide/reactivity.html#Change-Detection-Caveats
In this section of the documentation, a caveat of Vue's change detection is discussed:
Vue cannot detect property addition or deletion. Since Vue performs the getter/setter conversion process during instance initialization, a property must be present in the data object in order for Vue to convert it and make it reactive.
When, in my game run-time, I set players like so:
gameObj.gameState.players[user.id] = {...playerData}
I am adding a new property that Vue has not converted on initialization, and Vue does not detect this change. This is a simple concept I failed to take into account when developing my game run-time.
In order to correctly set a new player, I've decided to use the spread operator to change the entirety of the players object, which Vue is reacting to, and in turn, Vue will detect my player being added like so:
gameObj.gameState.players = {
...gameObj.gameState.players,
[user.id]: {...playerData}
}
Vue also discusses another method called $set, which you can read on the same page.

Change vue data from promise callback

I'm trying to change my Vue data from inside a promise callback,
and for some reason, I can't see the value changes in the template,
I saw this question how to update a vue's property in a promise call back?
and I've changed the this to the correct one, but still, I can't see the value changing in the template.
this is my template:
<template>
{{ sites }}
</template>
and this is my script:
data: () => ({
sites: {}
}),
methods: {
initialize(snapshot) {
let _this = this
snapshot.forEach((site) => {
convert(site.data())
.then(converted => {
_this.sites[site.id] = converted
})
})
}
}
any idea why my data won't change?

I think it's reactive issue. Please try
.then(converted => {
const sites = JSON.parse(JSON.stringify(_this.sites))
sites[site.id] = converted
_this.sites = sites
}
More explanation:
To update page, Vue does cheap comparison (as I understand, reference comparison). If you only update an attribute of object, they still point to same reference -> Vue will not update page. So we need to make deep copy them to make the comparison work

Deep autorun on MobX array of objects

I've looked at this issue on Github and this question on stackoverflow but am still unsure how to trigger an autorun for the data structure I have. I get the data from storage as a json object.
// Object keys do not change
const sampleData =
[
{
"title": "some-title",
"isActive": true,
"isCaseSensitive": false,
"hidePref": "overlay",
"tags": ["tag1", "tag2"]
},
{
"title": "all-posts",
"isActive": false,
"isCaseSensitive": true,
"hidePref": "overlay",
"tags": ["a", "b", "c"]
}
];
class Store {
#observable data;
constructor() {
this.data = getDataFromStorage();
if (this.data === null) {
this.data = sampleData;
}
}
}
const MainStore = new Store();
autorun(() => {
console.log("autorun");
sendPayloadToAnotherScript(MainStore.data);
})
How do I get autorun to run every time a new object is added to the data array, or any of the field values in the objects are changed?

The easiest way to get this working is to use JSON.stringify() to observe all properties recursively:
autorun(() => {
console.log("autorun");
// This will access all properties recursively.
const json = JSON.stringify(MainStore.data);
sendPayloadToAnotherScript(MainStore.data);
});

Mobx-State-Tree getSnapshot also works. And even though I can't find it right now: I read that getSnapshot is super-fast.
import { getSnapshot } from 'mobx-state-tree'
autorun(() => {
console.log("autorun");
// This will access all properties recursively.
getSnapshot(MainStore.data);
sendPayloadToAnotherScript(MainStore.data);
});

JSON.stringify() or getSnapshot() is not the right way to do it. Because that has a big cost.
Too Long => First part explains and shows the right way to do it. After it, there is also the section that shows how the tracking and triggering work through objects and arrays observables. If in a hurry Make sure to skim. And to check those sections: Track arrays like a hero show direct examples that work well. Code Illustration speaks better shows what works and what doesn't. Know that the starting explanation clear all. The last section is for the depth people who want to get a slight idea about how mobx manages the magic.
From the documentation you can read how reactivity work. What autorun() or reaction() react to and trigger.
https://mobx.js.org/understanding-reactivity.html
To resume it:
Object or arrays. Will make an autorun react if you make an access to it. mobx track accesses and not changes
That's why if you do
autorun(() => {
console.log(someObservable)
})
it wouldn't react on a change on the someObservable.
Now the confusing thing for people. Is ok but I'm making an access on the observable that holds the array property (in the question example that's MainStore object). And that should make it trackable (MainStore.data is being tracked.).
And yes it is
However. For a change to trigger a reaction. That change should come from an assignment or mutation that is tracked by the observable proxy. In arrays that would be a push, splice, assignment to an element by index and in objects that only can be an assignment to a prop value.
And because our observable that holds the array is an object. So to have a change for the array property to trigger the reaction through that object observable it needs to come from an assignment store.myArray = [].
And we don't want to do that. As a push is more performing.
For this reason. U need to rather make the change on your array. Which is an observable. And to track your array rather than the prop of the object. You have to make access in the array. You can do that through array.length or array[index] where index < length a requirement (because mobx doesn't track indexes above the length).
Note that:
observableObject.array = [...observableObject.array, some] or observableObject.array = observableObject.array.slice() //... (MainStore.data when making change. Instead of MainStore.data.push(). MainStore.data = [...MainStore.data, newEl]) would work and trigger the reaction. However using push would be better. And for that better we track the array. And so
Track arrays like a hero (.length)
autorun(() => {
console.log("autorun");
// tracking
MainStore.data.length
// effect
sendPayloadToAnotherScript(MainStore.data);
})
// or to make it cleaner we can use a reaction
reaction(
() => [MainStore.data.length], // we set what we track through a first callback that make the access to the things to be tracked
() => {
sendPayloadToAnotherScript(MainStore.data);
}
)
A reaction is just like an autorun. With the granulity of having the first expression that allow us to manage the access and what need to be tracked.
All is coming from the doc. I'm trying to explain better.
Code Illustration speaks better
To illustrate the above better let me show that through examples (both that works and doesn't work):
Note: autorun will run once a first time even without any tracking. When we are referring to NOT trigger reaction is talking about when change happen. And trigger at that point.
Array observable
const a = observable([1, 2, 3, 4])
reaction(
() => a[0], // 1- a correct index access. => Proxy get() => trackable
() => {
console.log('Reaction effect .......')
// 3- reaction will trigger
}
)
a.push(5) // 2- reaction will trigger a[0] is an access
const a = observable([1, 2, 3, 4])
reaction(
() => a.length, // 1- a correct length access. => Proxy get() => trackable
() => {
console.log('Reaction effect .......')
// 3- reaction will trigger
}
)
a.push(5) // 2- reaction will trigger a.length is a trackable access
const a = observable([1, 2, 3, 4])
reaction(
() => a.push, // an Access but. => Proxy get() => not trackable
() => {
console.log('Reaction effect .......')
// reaction will NOT trigger
}
)
a.push(5) // reaction will NOT trigger a.push is not a trackable access
Object observable
const o = observable({ some: 'some' })
autorun(() => {
const some = o.some // o.some prop access ==> Proxy get() => trackable
console.log('Autorun effect .........')
})
o.some = 'newSome' // assignment => trigger reaction (because o.some is tracked because of the access in autorun)
const o = observable({ some: 'some' })
autorun(() => {
const somethingElse = o.somethingElse // access different property: `somethingElse` prop is tracked. But not `some` prop
console.log('Autorun effect .........')
})
o.some = 'newSome' // assignment => reaction DOESN'T run (some is not accessed so not tracked)
const o = observable({ some: 'some' })
autorun(() => {
console.log(o) // NO ACCESS
console.log('Autorun effect .........')
})
o.some = 'newSome' // assignment => reaction DOESN'T Run (No access was made in the reaction)
let o = observable({ some: 'some' })
autorun(() => {
const some = o.some // Access to `some` prop
console.log('Autorun effect .........')
})
o = {} // assignment to a variable => reaction DOESN'T Run (we just replaced an observable with a new native object. No proxy handler will run here. yes it is stupid but I liked to include it. To bring it up. As we may or some may forget themselves)
Object observables with arrays observables as props
const o = observable({ array: [0,1,2,3] }) // observable automatically make
// every prop an observable by default. transforming an Arry to an ObservableArray
autorun(() => {
const arr = o.array // tracking the array prop on the object `o` observable
console.log('Autorun effect .........')
})
o.array.push(5) // will NOT trigger the rection (because push will trigger on the array observable. Which we didn't set to be tracked. But only the array prop on the o Observable)
o.array = [...o.array, 5] // assignment + ref change => Will trigger the reaction (Assignment to a prop that is being tracked on an object)
o.array = o.array.slice() // assignment + ref change => Will trigger the reaction (Assignment to a prop that is being tracked on an object)
o.array = o.array // Assignment => But DOESN'T RUN the reaction !!!!!!!!!
// the reference doesn't change. Then it doesn't count as a change !!!!!
const o = observable({ array: [0,1,2,3] })
autorun(() => {
const arr = o.array // tracking the array prop on the object `o` observable
const length = o.array.length // We made the access to .length so the array observable is trackable now for this reaction
console.log('Autorun effect .........')
})
o.array.push(5) // will trigger reaction (array is already tracked .length)
o.array = [...o.array, 5] // assignment => Will trigger the reaction too (Assignment to a prop that is being tracked on an object)
// Push however is more performing (No copy unless the array needs to resize)
With that, you have a great perception. Normally the whole cases are well covered.
What about with react-rerendering
The same principle apply with observer() higher order component factory. And the how the tracking happen within the render function of the component.
Here some great examples from an answer I wrote for another question
https://stackoverflow.com/a/73572516/7668448
There is code examples and playgrounds too where u can easily test for yourself on the fly.
How the tracking and the triggering happen
Observables are proxy objects. By making an access to a prop => we trigger the proxy methods that handle that operation. store.data will trigger the get() method of the proxy handler. And at that handler method. The tracking code run and that way mobx can follow all accesses. Same thing for store.data = []. That would trigger the set() method of the handler. Same for store.data[0] = 'some', however this would happen at the store.data proxy object (array observable) rather then the store itself. store.data.push() would trigger the get() method of the proxy. And then it would run the condition that check that it's push prop.
new Proxy(array, {
get(target, prop, receiver) {
if (prop === 'push') {
// handle push related action here
return
}
// ....
// handle access tracking action here
}
set(obj, prop, value) {
// if prop was an observable make sure the new value would be too
// Don't know how mobx does it. Didn't take the time to check the code
if (isObservable(obj[prop]) && !isObservable(value)) {
value = observable(value)
}
obj[prop] = value
// handle assignment change neededactions
}
})
Actually, I got a bit curious. And went and checked the actual mobx implementation. And here are some details:
For the arrayObservable here are the details:
The proxy handler are defined in arrayTraps
src/types/observablearray.ts#L84
We can see every target (element that was made an observable). Have a $mobx property that have an
As shown here src/types/observablearray.ts#L86
$mobx if curious it's just a Symbol export const $mobx = Symbol("mobx administration")src/core/atom.ts#L17
And you can see how the administration object is used to handle all. That handle the actions and magic of tracking.
const arrayTraps = {
get(target, name) {
const adm: ObservableArrayAdministration = target[$mobx]
if (name === $mobx) {
// if $mobx (requiring the administration) just forward it
return adm
}
if (name === "length") {
// if length ==> handle it through administration
return adm.getArrayLength_()
}
if (typeof name === "string" && !isNaN(name as any)) {
// all proxy names are strings.
// Check that it is an index. If so handle it through the administration
return adm.get_(parseInt(name))
}
// Up to now ==> if $mobx, length or 0, 1, 2 ....
// it would be handled and for the two later through administration
if (hasProp(arrayExtensions, name)) {
// If it's one of the extension function. Handle it through
// the arrayExtensions handlers. Some do extra actions like
// triggering the process of handling reactions. Some doesn't
return arrayExtensions[name]
}
// if none of the above. Just let the native array handling go
return target[name]
},
set(target, name, value): boolean {
const adm: ObservableArrayAdministration = target[$mobx]
if (name === "length") {
// Handle length through administration
adm.setArrayLength_(value)
}
if (typeof name === "symbol" || isNaN(name)) {
target[name] = value
} else {
// numeric string
// handle numeric string assignment through administration as well
adm.set_(parseInt(name), value)
}
return true
},
preventExtensions() {
die(15)
}
}
Through arrayExtensions. There is those that are handled through the same simpleFunc.
src/types/observablearray.ts#L513
And you can see how calling such calls and through the proxy (get handler). Those calls signal that the observable is being observed and the dehancedValues are managed that are recovered from the administration object. src/types/observablearray.ts#L545
For the other arrayExtensions that have special handling like push we can see how it's triggering the process of signaling change. src/types/observablearray.ts#L457
First we can see that push is using splice handling of the administration. Making push and splice to be handled by the same handler. reusability
You can check this part that seems to be the part for push or splice that trigger and handle interceptors src/types/observablearray.ts#L238
Interceptors as by doc ref
For change notification and reaction triggering this code here
src/types/observablearray.ts#L261 does that handling. You can see it through this line src/types/observablearray.ts#L337
this.atom_.reportChanged()
// conform: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/observe
if (notify) {
notifyListeners(this, change)
}
src/types/observablearray.ts#L256 show how the length is tracked and used and it check if the internal array is modified. To show that mobx does track many things. Or does check.
If you are more curious. You can dig further. But through the above you can already have a good idea how mobx manage it's magic. And understanding how mobx track (still not fully in depth) and also how the observable that are proxies and how proxies works. All that help well.
Here extra links:
packages/mobx/src/types/observablearray.ts
packages/mobx/src/types/observableobject.ts
packages/mobx/src/types/dynamicobject.ts
packages/mobx/src/types/observablemap.ts
packages/mobx/src/types/observableset.ts
packages/mobx/src/types/observablevalue.ts
packages/mobx/src/utils/utils.ts
If you check those links. You would notice that ObservableMap, ObservableSet, ObservableValue all doesn't use proxies. And make a direct implementation. Make sense for Set and Map. As you would just make a wrapper that keep the same methods as the native one. Proxies are for overriding operators. Like property access. And assignment operations.
You would notice too. That ObservableObject have the administration implementation that account for both proxies and annotation. And only the ObservableDynamicObject that implement the proxy, . And using the ObservableObjectAdministration. you can find the proxy traps there too.
Again, you can dig further if you want.
Otherwise, that's it. I hope that explained the whole well and went to some depth.