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.
Related
I'm having trouble understanding why, when there are objects inside the vector, it doesn't create new references to them when copying the vector.
But here's the problem.
const USERS_TYPE = [
{name:"User",icon:faTruck,
inputs:[
{label:"Name",required:true,width:"200px",value:"", error:false},
{label:"ID",required:true,width:"150px",value:"", error:false},
{label:"Email",required:false,width:"150px",value:"", error:false},
]}]
I tried to pass this vector to a state in two ways.
const [users,setUsers] = useState(USERS_TYPE.map(item=>({...item})))
const [users,setUsers] = useState([...USERS_TYPE])
And in both situations changing user with setUser will change USERS_TYPE.
One of the ways I change.
const changes = [...users]
const err = validation(changes[selected-1].inputs)
err.map((index)=>{
changes[selected-1].inputs[index].error = true
})
setUsers(changes)
What solutions could I come up with, change from vector to object, another copy mechanism.
This copy doesn't make much sense as the internal object references remain intact.
Edit: Another important detail is that the USER_TYPE is outside the function component.
it doesn't create new references to them when copying the vector
Because that's not the way JS works. It doesn't deep clone stuff automagically.
const user1 = {id:1}
const user2 = {id:2}
const users = [user1,user2];
const newUsers = [...users]; // this clones users, BUT NOT the objects it contains
console.log(newUsers === users); // false, it's a new array
console.log(newUsers[0] === users[0]) // true, it's the same reference
Ultimately, you are just mutating state. First and most golden rule of react: don't mutate state.
This is the line causing the error:
err.map((index)=>{
// you are mutating an object by doing this
// yes, `changes` is a new array, but you are still mutating the object that is part of state that is nested inside of that array
changes[selected-1].inputs[index].error = true
})
Maybe this would work:
const idx = selected-1;
const err = validation(users[idx].inputs)
setUsers(users => users.map((user,i) => {
if(i !== idx) return user; // you aren't interested in this user, leave it unmodified
// you need to change the inputs for this user
// first, shallow clone the object using the spread operator
return {
...user,
// now inputs must be a new reference as well, so clone it using map
inputs: user.inputs.map((input,index) => ({
// careful not to mutate the input object, clone it using spread
...input,
// and set the error property on the cloned object
error: !!err[index]
}))
}
}))
EDIT: Sorry for all the code edits, I had a bunch of syntax errors. The ultimate point I was trying to get across remained consistent.
EDIT #2:
Another important detail is that the USER_TYPE is outside the function component.
That doesn't really matter in this case as it serves as your initial state. Every time you update state you need to do it immutably (as I've shown you above) so as not to mutate this global object. If you actually mutate it, you'll see that by unmounting the component and re-mounting the component will result in what looks like "retained state" - but it's just that you mutated the global object that served as the template for initial state.
Mobx supports both #observable and #observable.ref modifiers and their official doc says
observable: This is the default modifier, used by any observable. It clones and converts any (not yet observable) array, Map or plain object into it's observable counterpart upon assignment to the given property
observable.ref: Disables automatic observable conversion, just creates an observable reference instead.
I do not understand why would we need to create a observable reference for an already existing observable. How are these two different and what are their use cases ?
observable.ref will only track reference changes to the object, which means that you will need to change the whole object in order to trigger the reaction. So if you, for example, have an observable array that is tracked by reference, the contents of the array will not be tracked. Also if you add items to the array that change will also not be tracked.
import { observable, reaction } from "mobx";
const test = observable(
{
reference: [{ id: 1 }]
},
{
reference: observable.ref
}
);
reaction(
() => {
return test.reference.length;
},
() => {
console.log("Reaction 1: reference length changed");
}
);
reaction(
() => {
return test.reference[0];
},
() => {
console.log("Reaction 2: reference item changed");
}
);
test.reference[0] = { id: 2 }; // this will not trigger the reactions
test.reference.push({ id: 3 }); // this will not trigger the reactions
test.reference.pop(); // this will not trigger the reactions
test.reference = []; // this will trigger both reactions
code sandbox example
I'd like to explain the Ivan V.'s answer.
In his code, test.reference is a reference which will not change the address of the variable in the memory until reassign.
operations like push/pop or edit the value of test.reference[0] just change the value instead of the variable's reference.
So when using the #observable.ref, mobx will compare the memory address of the variable which is observed.But when using the #observable, mobx will compare the variable's value to decide to trigger the reactions.
I'm coding a game in which the character can fire their weapon.
I want different things to happen when the player tries to fire, depending on whether they have ammo.
I reduced my issue down to the following code (btw I'm not sure why SO's snippet feature does not work, so I made CodePen where you can try out my code).
const { from, merge } = rxjs;
const { partition, share, tap } = rxjs.operators;
let hasAmmo = true;
const [ fire$, noAmmo$ ] = from([true]).pipe(
share(),
partition(() => hasAmmo),
);
merge(
fire$.pipe(
tap(() => {
hasAmmo = false;
console.log('boom');
}),
),
noAmmo$.pipe(
tap(() => {
console.log('bam');
}),
)
).subscribe({
next: val => console.log('next', val),
error: val => console.log('error', val),
complete: val => console.log('complete', val),
});
<script src="https://cdnjs.cloudflare.com/ajax/libs/rxjs/6.3.3/rxjs.umd.js"></script>
When I run this code I get the following:
"boom"
"next" true
"bam"
"next" true
"complete" undefined
I don't understand why I get a "bam".
The first emission goes to fire$ (I get a "boom"), which makes sense because hasAmmo is true. But as a side-effect of fire$ emitting is that the result of the partition condition changes, which I guess is causing me to get a "bam".
Am I not supposed to cause side-effects that affect partition()?
Or maybe is there an issue with the way I share() my parent observable? I may be wrong but I would intuitively think the fire$ and noAmmo$ internally subscribe to the parent in order to split it, in which case share() should work?
It actually works correctly. The confusion comes from the partition operator which is basically just two filter operators.
If you rewrite it without partition it looks like this:
const fire$ = from([true]).pipe(
share(),
filter(() => hasAmmo),
);
const noAmmo$ = from([true]).pipe(
share(),
filter(() => !hasAmmo),
);
Be aware that changing hasAmmo has no effect on partition itself. partition acts only when it receives a value from its source Observable.
When you later use merge() it makes two separate subscriptions to two completely different chains with two different from([true])s. This means that true is passed to both fire$ and noAmmo$.
So share() has no effect here. If you want to share it you'll have to wrap from before using it on fire$ and noAmmo$. If the source Observable is just from it's unfortunately going to be even more confusing because the initial emission will arrive only to the first subscriber which is fire$ later when used in merge:
const shared$ = from([true]).pipe(
share(),
);
const fire$ = shared$.pipe(...);
const noAmmo$ = shared$.pipe(...);
The last thing why you're receiving both messages is that partition doesn't modify the value that goes through. It only decides which one of the returned Observable will reemit it.
Btw, rather avoid partition completely because it's probably going to be deprecated and just use filter which is more obvious:
https://github.com/ReactiveX/rxjs/issues/3797
https://github.com/ReactiveX/rxjs/issues/3807
I am trying to wrap my head around observables. I know when a value changes in observer, observable notify all its subscriber that something has changed. I am not sure why below code doesn't work. my understading is that once i add another element in array, subscriber should log new value or maybe log all values.
can someone please explain why is that?
import { Observable } from 'rxjs';
var numbers = [5, 1, 2, 7, 10];
// let source = Observable.from(numbers);
let source = Observable.create(observer => {
for (let n of numbers)
observer.next(n);
observer.complete();
});
source.subscribe(
value => console.log(`value is ${value}`),
error => console.log(`error is ${error}`),
() => console.log(`completed!`)
);
setTimeout(function () {
console.log("pushing new value");
numbers.push(33);
}, 3000);
I tried commenting observer.complete() as I thought that might be the culprit.
The observable from operator ( which is similar to the observable you've created ) does not 'listen' the array for it's onPush event ( no array has one in the default implementation ). The values you will get from the stream will be the one inside the array just before the subscribe call. The observable per se is just a function, it will just "copy" those values and emit them one by one, your array does not know how to "push" values to the stream. In the reactive world, everithing is a stream, most of the values you would store inside an array are stored in a stream of those values.
I am using Firebase and Node with Redux. I am loading all objects from a key as follows.
firebaseDb.child('invites').on('child_added', snapshot => {
})
The idea behind this method is that we get a payload from the database and only use one action to updated my local data stores via the Reducers.
Next, I need to listen for any NEW or UPDATED children of the key invite.
The problem now, however, is that the child_added event triggers for all existing keys, as well as newly added ones. I do not want this behaviour, I only require new keys, as I have the existing data retrieved.
I am aware that child_added is typically used for this type of operation, however, i wish to reduce the number of actions fired, and renders triggered as a result.
What would be the best pattern to achieve this goal?
Thanks,
Although the limit method is pretty good and efficient, but you still need to add a check to the child_added for the last item that will be grabbed. Also I don't know if it's still the case, but you might get "old" events from previously deleted items, so you might need to watch at for this too.
Other solutions would be to either:
Use a boolean that will prevent old added objects to call the callback
let newItems = false
firebaseDb.child('invites').on('child_added', snapshot => {
if (!newItems) { return }
// do
})
firebaseDb.child('invites').once('value', () => {
newItems = true
})
The disadvantage of this method is that it would imply getting events that will do nothing but still if you have a big initial list might be problematic.
Or if you have a timestamp on your invites, do something like
firebaseDb.child('invites')
.orderByChild('timestamp')
.startAt(Date.now())
.on('child_added', snapshot => {
// do
})
I have solved the problem using the following method.
firebaseDb.child('invites').limitToLast(1).on('child_added', cb)
firebaseDb.child('invites').on('child_changed', cb)
limitToLast(1) gets the last child object of invites, and then listens for any new ones, passing a snapshot object to the cb callback.
child_changed listens for any child update to invites, passing a snapshot to the cb
I solved this by ignoring child_added all together, and using just child_changed. The way I did this was to perform an update() on any items i needed to handle after pushing them to the database. This solution will depend on your needs, but one example is to update a timestamp key whenever you want the event triggered. For example:
var newObj = { ... }
// push the new item with no events
fb.push(newObj)
// update a timestamp key on the item to trigger child_changed
fb.update({ updated: yourTimeStamp })
there was also another solution:
get the number of children and extract that value:
and it's working.
var ref = firebaseDb.child('invites')
ref.once('value').then((dataSnapshot) => {
return dataSnapshot.numChildren()
}).then((count) =>{
ref .on('child_added', (child) => {
if(count>0){
count--
return
}
console.log("child really added")
});
});
If your document keys are time based (unix epoch, ISO8601 or the firebase 'push' keys), this approach, similar to the second approach #balthazar proposed, worked well for us:
const maxDataPoints = 100;
const ref = firebase.database().ref("someKey").orderByKey();
// load the initial data, up to whatever max rows we want
const initialData = await ref.limitToLast(maxDataPoints).once("value")
// get the last key of the data we retrieved
const lastDataPoint = initialDataTimebasedKeys.length > 0 ? initialDataTimebasedKeys[initialDataTimebasedKeys.length - 1].toString() : "0"
// start listening for additions past this point...
// this works because we're fetching ordered by key
// and the key is timebased
const subscriptionRef = ref.startAt(lastDataPoint + "0");
const listener = subscriptionRef.on("child_added", async (snapshot) => {
// do something here
});