I want to make use of the structuredClone() function inside my Vue app. I want to use this to create a deep clone ( instead of using workarounds like stringify and parse or external libraries ). Inside my setup function the following code is fine
const a = {
foo: {
bar: "+"
}
};
const b = structuredClone(a);
console.log(b);
But it is not possible for me to use it on values of ref variables. This example code
import { ref } from "vue";
const a = ref({ foo: { bar: "+" } });
const b = structuredClone(a.value);
throws the error
Uncaught DOMException: Failed to execute 'structuredClone' on 'Window': # could not be cloned.
The same goes for items from ref arrays
import { ref } from "vue";
const a = ref([{ foo: { bar: "+" } }]);
for (const b of a.value) {
const c = structuredClone(b);
}
How can this be fixed?
The error means that structuredClone was executed on Proxy instance, which cannot be cloned. In order to allow this, it should be used on raw object that a proxy wraps:
const b = structuredClone(toRaw(a.value));
Notice that toRaw is used on a.value because both a and a.value are reactive objects, and toRaw works shallowly and needs to be applied to the innermost object.
Since ref and reactive allow to compose reactive objects, toRaw still may not work for them due to how it works:
ref({ foo: { bar: barRef } })
This would require to recursively use toRaw on reactive objects before using structuredClone. At this point this doesn't make it easier than cloning the objects manually, unless more exotic objects like Set, Map, etc are in use.
Related
first of all i get my redux array then in my_function copy that into new variable like below :
let transactions_list = useSelector(state => state.transactions_list.value);
let new_transactions_list = [...transactions_list];
when i want to change my new_transactions_list very deeply i got the error
const my_function = () => {
let new_transactions_list = [...transactions_list];
new_transactions_list[yearIndex].data_yearly[monthIndex].data_monthly.push(new_obj);
}
but when i define an array in class(without redux), it's work
Even if you are using the spreading [...transactions_list], you are still only copying the first level of the array, which means that the object below that array is still the same one that redux uses.
You have 2 options:
This is how redux recommends you to update nested object link
function updateVeryNestedField(state, action) {
return {
...state,
first: {
...state.first,
second: {
...state.first.second,
[action.someId]: {
...state.first.second[action.someId],
fourth: action.someValue
}
}
}
}
}
Or you can use something like immer, which will allow you to update your object even with immutable like this
const nextState = produce(baseState, draft => {
draft[1].done = true
draft.push({title: "Tweet about it"})
})
Either way, you will have to update your redux state afterward since this change will only be local in your code and not the global redux.
I want to use a Pinia store in a component of my Vue app and I can't figure out why the store has to be returned in { }? What is the difference between return {foo} vs return foo?
import { usePiniaStore } from "../stores/mainStore";
export default {
setup() {
const piniaStore = usePiniaStore();
return { piniaStore }; // why isn't it 'return piniaStore' ?
},
};
This is really not about Pinia but about what Vue expects as a return value from setup() function. It expects an object. If you try to return something else, Vue gives you an error.
// this will give you an error "setup() should return an object. Received: number"
<script>
import { defineComponent } from 'vue'
export default defineComponent({
setup() {
let myVariable = 10
return myVariable
}
})
</script>
Reason for this is that Vue needs to iterate the properties of returned object (so it knows both the value and it's name) and create properties with same names on component instance (so they are accessible in template). This is important.
The code from your example:
return { piniaStore }
is actually same as:
// creating new JS object
const returnObject = {
// first is property name
// second is property value (from existing variable)
piniaStore: piniaStore
}
return returnObject
...and it is a valid code from Vue's point of view
Important thing to remember is that only properties of the returned object are accessible from the template
// you can do this BUT only inner properties of the "myObject" will be accessible in the template
<script>
import { defineComponent } from 'vue'
export default defineComponent({
setup() {
let myObject = {
variableA: 10,
variableB: "some string"
}
return myObject
}
})
</script>
Using <div v-if="variableA"> will work. Using <div v-if="myObject"> will not.
Pinia stores are actually objects so returning them directly from setup (without wrapping them in another object) is probably legal and will work. But all above still applies. Your template has no access to piniaStore only to properties (state or getters) and functions (actions) defined on that piniaStore store
This is called Object Destructring. If a module is returning multiple objects ie {foo, goo, loo} and you want to pick just one foo. you can use return {foo}.
But if the module is returning only one object foo, you can use return foo.
https://www.javascripttutorial.net/es6/javascript-object-destructuring/
Imagine I have an object with several props that I want to bring into a variety of vue components' "data" state as sort of a starting point or default state. I want each component to be able to manage its own state going forward from the moment of its initialization.
Something like:
import { initialData } from '../../some-data.js'
Vue.component('my-component', {
data: function () {
return {
...initialData,
somethingElse: 'hello there",
}
},
template: 'Hi'
})
Will Vue make a deep copy of this object so that when it is mutated by user interaction the original object (sitting in some-data.js) will not be mutated or will I need to do that myself using something like:
import { initialData } from '../../some-data.js'
Vue.component('my-component', {
data: function () {
return {
...JSON.parse(JSON.stringify(initialData)),
somethingElse: 'hello there'
}
},
template: 'Hi'
})
Thanks.
Will Vue make a deep copy of this object
A deep copy? No, but you will get a shallow copy for that component because you are creating a new object (with spread syntax).
As with any shallow copy, if initialData contains objects then those objects will not be deep copied, but top-level strings and numbers (etc) will be copied.
Using JSON.parse to do a deep copy is kind of a hack. It's better to use a dedicated deep copy method like lodash _.cloneDeep. Or you can just write initialData as a factory function:
const createInitialData = () => ({
foo: 'bar',
nestedObject: {
blah: 12345
}
})
data() {
return {
...createInitialData(),
somethingElse: 'hello there'
}
}
Why not try and see what happens?
In some-data.js file at the end add something like:
setInterval(function() { console.log(initialData) }, 1000);
Then when you're importing it, modify something and see what happens with the logs.
Whatever the case is you should probably use Vuex.
I am using immer to transform react/redux state. Can I also use immer to just deep copy an object without transforming it?
import produce, {nothing} from "immer"
const state = {
hello: "world"
}
produce(state, draft => {})
produce(state, draft => undefined)
// Both return the original state: { hello: "world"}
This is from the official immer README. Does this mean that passing an empty function to produce returns a deep copy of the original state or actually the original state?
Thank you very much for your help :)!
This is easily testable with
import { produce } from 'immer'
const state = {
hello: 'world',
}
const nextState = produce(state, draft => {})
nextState.hello = 'new world'
console.log(state, nextState)
which outputs
Object { hello: "new world" }
Object { hello: "new world" }
which means that it does NOT create a deep copy of an object.
UPDATE:
So I got interested and tested out the library a lot and here are my findings.
The code snippet I wrote above is simply an optimisation in the library which returns the old state if no changes are made. However, if you make some changes, then the library starts functioning as intended and the mutation later is made impossible. That is,
const state = {
hello: 'world',
}
const nextState = produce(state, draft => {
draft.hello = 'new world';
})
nextState.hello = 'newer world';
console.log(state, nextState)
will result in an error: TypeError: "world" is read-only
Which means that your newState is immutable and you can no longer perform mutations on it.
Another rather interesting thing I found is that immer fails when using class instances. That is,
class Cls {
prop = 10;
}
const instance = new Cls();
const obj = {
r: instance,
};
const newObj = produce(obj, draft => {
draft.r.prop = 15;
});
console.log(obj, newObj);
results in
r: Object { prop: 15 }
r: Object { prop: 15 }
So to get back to the initial question, can you get a deep copy of the initial Object by changing nothing in the draft. No you cannot, and even if you did (by changing a property created just to fool immer perhaps), the resultant cloned object will be immutable and not really helpful.
Solution :
The Immer's produce only provides a new deep cloned object on updation.
you can create your own produce function that behaves just like that of immer's produce but gives a cloned object everytime using loadash
import _ from 'lodash';
export default function produceClone(object, modifyfunction) {
let objectClone = _.cloneDeep(object);
if (!modifyfunction) return objectClone;
modifyfunction(objectClone);
return objectClone;
}
This will give you a deepCloned(or deep copied) object everytime, irrespective of whether you modify the object or not.
I have a fairly deep interface declared that looks something like this:
export interface Job {
JobId: JobId; // type JobId = string
UserId: UserId; // type UserId = string
JobName: string;
AudioFile: JobAudioFile; // this is an interface
Status: JobStatus; // this is an enum
Tracks: JobTracks[]; // 'JobTracks' is an enum
Results: JobResults; // this is an interface
Timestamps: JobTimestamps // interface
}
Most of the members of this interface are themselves interfaces, with the general architecture following this pattern of using enums, strings, arrays and more interfaces. All code is written as TypeScript, transpiled down to JS and uploaded to AWS as JS. (Node 8.10 is running on AWS)
At one point in the code, I need to make a deep copy of a Job instantiation which was passed in as a function parameter:
export const StartPipeline: Handler = async (
event: PipelineEvent
): Promise<PipelineEvent> => {
console.log('StartPipeline Event: %o', event);
const newBucket = await copyToJobsBucket$(event.Job);
await deleteFromOriginalBucket$(event.Job);
console.log(`Job [${event.Job.JobId}] moved to Jobs bucket: ${newBucket}`);
event.Job.AudioFile.Bucket = newBucket;
event.Job.Status = Types.JobStatus.Processing;
// update the job status
// VVV PROBLEM OCCURS HERE VVV
const msg: Types.JobUpdatedMessage = new Types.JobUpdatedMessage({ Job: Object.assign({}, event.Job) });
await Send.to$(event.Job.UserId, msg);
return { ...event };
};
The definition of the JobUpdatedMessage:
export class JobUpdatedMessage extends BaseMessage {
constructor(payload: { Job: Types.Job }) {
console.log('Incoming: %o', payload);
const copy: object = { ...payload.Job };
// VVV PROBLEM ON NEXT LINE VVV
const filtered = JobUtils.FilterJobProperties(copy as Types.Job);
super(MessageTypes.JobUpdated, filtered);
}
}
The problem is after the call to JobUtils.FilterJobProperties, payload.Job has also been mutated in an undesirable and unexpected way.
Here's the implementation of JobUtils.FilterJobProperties:
export const FilterJobProperties = (from: Types.Job): Types.Job => {
const fieldsToRemove: string[] = [
'Transcripts.GSTT',
'Transcripts.WSTT',
'Transcripts.ASTT',
'TranscriptTracks',
'Transcripts.Stream.File',
'Transcripts.Stream.State',
'AudioFile.Bucket',
'AudioFile.S3Key',
];
let job: Types.Job = { ...from }; // LINE ONE
fieldsToRemove.forEach(field => _.unset(job, field)); // LINE TWO
return job;
};
(I'm using the lodash library here)
The line market 'LINE TWO' is also mutating the from function parameter, even though on 'LINE ONE' I'm doing what I think is a deep clone of from.
I know that this is the case because if I change 'LINE ONE' to:
// super hard core deep cloning
let job: Types.Job = JSON.parse(JSON.stringify(from));
... everything works as expected. from is not mutated, the resulting JobUpdatedMessage is as expected, and StartPipeline's event parameter doesn't have a bunch of properties removed from event.Job.
I struggled with hours on this, including relearning everything I believed I knew about cloning objects in Es6 using the spread operator.
Why was 'LINE ONE' mutating the input as well?
Spread operator does shallow cloning same as Object.assign()
Shallow-cloning (excluding prototype) or merging of objects is now
possible using a shorter syntax than Object.assign().
Spread operator
An example to understand spread operator and shallow cloning.
let obj = { 'a': { 'b' : 1 },'c': 2}
let copy = {...obj}
copy.c = 'changes only in copy' //shallow-cloned
copy.a.b = 'changed' // still reference
console.log('original\n',obj)
console.log('\ncopy',copy)
Using spread operator object is shallow cloned so all the first level properties will become a copy while all the deeper level properties will still remain the references.
so as you see in example c property doesn't affect the original object since it is one first level depth, on the other hand b property changes affect the parent properties because it is at deep level and is still reference.