Can anyone further explain/elaborate on the following change in Meteor 1.9.1 from the History.md file? I couldn’t find any info on this anywhere.
cursor.observeChanges now accepts a second options argument. If your observer functions do not mutate the passed arguments, you can specify { nonMutatingCallbacks: true } , which improves performance by reducing the amount of data copies.
So if I make no changes to the arguments coming from .added, .changed, .removed, etc. before publishing them I should use this new nonMutatingCallbacks option?
So this is only talking about publication code then and not using observeChanges on the client (which I do often to “untether” default reactivity and modify the client how I choose)?
I’m trying to make sure I understand it.
1 Like
i guess cursor.observe now passes the original cache-objects to your callbacks when setting nonMutatingCallbacks to true. Without it will clone the objects which has a performance impact. The cloning was done to prevent devs from accidentially mutate these objects, because they are shared in the cache between different invocations and could lead to strange bugs. This could further help to check if objects have changed by checking if they are referentially equal: same object --> no change. (Many ui frameworks these days rely on shallow comparing objects to check whether they have changed).
It is generally a good practice to consider every object as immutable and every variable as constant and never reassign. The classic airbnb-lint rules also have rules to prevent this (e.g. “no param reassign”). Mutate an object --> create a new object.
To answer your specific questions:
- i think it refers mainly to client-code, but probably also applies to server code (custom publications)
- If you have good linting rules and never mutate function params, you can set
nonMutatingCallbacks to true. If you are unsure and have no performance problems, just leave it to false.
by the way, the apollo-client has a very similar approach of cloning objects from the cache before passing them to prevent people from manipulating objects in the cache. They also recently added an option to turn that off to increase performance.
My hope is that some kind of strict-mode will be standardized in a future Ecmascript version which makes everything immutable… At least immutability should be the default - not the other way around.
2 Likes
Not a new mode, but new always-immutable data types that would be perfect for this situation:
1 Like