You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
They are not equal because a new array is being created in each of these statements, each being a brand new array object with just identical contents. If you create two new objects:
21
+
22
+
var a = {};
23
+
var b = {};
24
+
25
+
a === b // false
26
+
27
+
When you create new objects, arrays, functions, etc., a brand new object is placed into memory. Creating a new object with the same internals as another object will not magically cause that object to point to one that already exists. The objects may look the same, but they do not point to the same instance.
28
+
29
+
Non-Primitive data-types like Objects are not compared by value. This means that even if two objects have the same properties and values, they are not strictly equal. Same goes for arrays. Even if they have the same elements that are in the same order, they are not strictly equal.
30
+
31
+
Non primitive values can also be referred to as reference types because they are being compared by reference instead of value. Two objects are only strictly equal if they refer to the same underlying object.
32
+
33
+
*/
34
+
35
+
// To understand better of the concept of 'pass-by-value' vs 'pass-by-reference'
When assigning a variable (a) a primitive value the equals operator sets up a location (address) in memory to store the information and points the variable (a) to that address. When you create a new variable (b in this case) and assign it the value of another variable (a) the equals operator creates ANOTHER spot in memory separate from the original variable and places of copy of (a) in the new variables spot in memory. So, 'pass-by-value' copies the value of the original variable (a) into two separate spots in memory.
52
+
53
+
In the above we assign variable (a) the value of 5. The equals operator notices the value is a primitive and creates a new location in memory, points (a) to the address, and fills it with the value 5. When we create variable (b) and assign it the value of (a) the equals operator notices we’re dealing with a primitive value (5 in this case) and creates a NEW location in memory, points (b) to the NEW address, and fills it with a copy of (a)’s value (5). The console.log() of each variable prints what we would expect (5) at this point. However, when we change the value of (a) to 1 and console.log both variables (a) prints 1 as expected, but (b) is still equal to 5. Why? Because as discussed earlier when we assigned (b) to equal (a) a new location in memory was created, the equals operator did not simply have (b) point to the same spot in memory that (a) does, (b) was given its own location filled with the value of (a) at that time (5). So when (a) was changed (b) does not follow suit because it’s pointing to it’s OWN spot in memory, it has no idea that (a)’s value has changed since that is an entirely separate address in memory.
54
+
*/
55
+
56
+
// Now pass-by-reference
57
+
leta={language: "Javascript"};
58
+
letb=a;
59
+
60
+
console.log(a);// => {language: "Javascript"}
61
+
console.log(b);// => {language: "Javascript"}
62
+
63
+
a.language="Ruby";
64
+
65
+
console.log(a);// => {language: "Ruby"}
66
+
console.log(b);// => {language: "Ruby"}
67
+
68
+
/*
69
+
2. Pass-By-Reference
70
+
71
+
Passing by reference relates to objects in Javascript (ALL objects including functions).
72
+
73
+
When a variable (a) is set equal to an object the equals operator identifies that the value is an object, creates a new location in memory, and points (a) to the address (represented by 0x001). When we create a new variable (b) and assign it the value of variable (a) the equals operator knows we are dealing with an object and points it to the same address that (a) points to.
74
+
Notice that no new location or object in memory is created (like in pass by value), rather variable (b) is simply pointed to the same address that variable (a) was pointed to.
75
+
76
+
In sum, ALL objects interact by reference in Javascript so when setting equal to each other or passing to a function they all point to the same location so when you change one object you change them all. This is a stark difference compared to pass by value.
Copy file name to clipboardExpand all lines: React/immutable-state-store-in-React-Redux-1.md
+22-5Lines changed: 22 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -8,11 +8,24 @@ One approach to controlling changes is to favor immutable, persistent data struc
8
8
9
9
The thing about immutable data structures is that, as the name implies, you can never mutate one, but only produce new versions of it. If you want to change an object's attribute, you'll need to make a new object with the new attribute, since you can't change the existing one. Because of the way persistent data structures work, this is actually much more efficient than it sounds.
10
10
11
-
#### What this means in terms of change detection is that when a React component's state consists of immutable data only, there's an escape hatch: When you're re-rendering a component, and the component's state still points to the same data structure (Meaning nothing was changed, i.e. no new Object was created or Cloned becuase there was no change) as the last time you rendered it, you can skip re-rendering. You can just use the previous virtual DOM for that component and the whole component tree stemming from it. There's no need to dig in further, since nothing could possibly have changed in the state.
11
+
#### What this means in terms of change detection is that when a React component's state consists of immutable data only, there's an escape hatch: When you're re-rendering a component, and the component's state still points to the same data structure (Meaning nothing was changed, i.e. no new Object was created or Cloned because there was no change) as the last time you rendered it, you can skip re-rendering. You can just use the previous virtual DOM for that component and the whole component tree stemming from it. There's no need to dig in further, since nothing could possibly have changed in the state.
12
12
13
-
### Pass by reference vs pass by value
13
+
### Pass by reference vs pass by value in pure JavaScript
14
14
15
-
**To understand immutable data you need to understand that in JavaScript non-primitive types (objects, arrays, functions…) are passed by reference and primitive types (string, number, boolean, symbol, null and undefined) are passed by value. This means that primitive types are immutable by default and you can’t change them. Instead, when you pass a primitive type to another variable, it will get a new copy of that value.**
15
+
**To understand immutable data you need to understand that in JavaScript non-primitive types (objects, arrays, functions…) are passed by reference and primitive types (string, number, boolean, symbol, null and undefined) are passed by value. This means that primitive types are immutable by default and you can’t change them. Instead, when you pass a primitive type to another variable, it will get a new copy of that value. On the other hand non-primitive or compound data types, which are mutable.**
16
+
17
+
Lets see an example
18
+
19
+
var a = {};
20
+
var b = {};
21
+
22
+
a === b // false
23
+
24
+
When you create new objects, arrays, functions, etc., a brand new object is placed into memory. Creating a new object with the same internals as another object will not magically cause that object to point to one that already exists. The objects may look the same, but they do not point to the same instance.
25
+
26
+
Non-Primitive data-types like Objects are not compared by value. This means that even if two objects have the same properties and values, they are not strictly equal. Same goes for arrays. Even if they have the same elements that are in the same order, they are not strictly equal.
27
+
28
+
Non primitive values can also be referred to as reference types because they are being compared by reference instead of value. Two objects are only strictly equal if they refer to the same underlying object.
#### So, how should you handle immutable data in JavaScript?
40
53
41
-
#### When you want to update an object you should create a completely new object, thus keeping it immutable. For that purpose you can use the Object.assign method or object spread syntax:
54
+
**MOST IMPORTANT POINT - When you want to update an object you should create a completely new object, thus keeping it immutable. For that purpose you can use the Object.assign method or object spread syntax:**
42
55
43
56
```js
44
57
constanimal= { name:"Mouse" };
@@ -84,7 +97,11 @@ By virtue of using immutability approach your state will become more predictable
84
97
85
98
**Redux takes a given state (object) and passes it to each reducer in a loop. And it expects a brand new object from the reducer if there are any changes. And it also expects to get the old object back if there are no changes.**
86
99
87
-
**Redux simply checks whether the old object is the same as the new object by comparing the memory locations of the two objects. So if you mutate the old object’s property inside a reducer, the “new state” and the “old state” will both point to the same object. Because, in JavaScript non-primitive types (objects, arrays, functions…) are passed by reference. Hence Redux thinks nothing has changed! So this won’t work.**
100
+
**Redux simply checks whether the old object is the same as the new object by comparing the memory locations of the two objects. Meaning if the memory-locations are different - its a change of State for Redux and re-rendering cycle is necessary, if memory-locations are same no change has occurred for Redux, so no re-rendering is required**
101
+
102
+
**So if you mutate the old object’s property inside a reducer, the “new state” and the “old state” will both point to the same object.**
103
+
104
+
**Because, in JavaScript non-primitive types (objects, arrays, functions…) are passed by reference. Hence Redux thinks nothing has changed! So this won’t work.**
Since one of the core tenets of Redux is to never mutate state, you'll often find yourself using Object.assign() to create copies of objects with new or updated values. For example, in the todoApp below Object.assign() is used to return a new state object with an updated visibilityFilter property:
2
+
3
+
```js
4
+
functiontodoApp(state=initialState, action) {
5
+
switch (action.type) {
6
+
caseSET_VISIBILITY_FILTER:
7
+
returnObject.assign({}, state, {
8
+
visibilityFilter:action.filter
9
+
});
10
+
default:
11
+
return state;
12
+
}
13
+
}
14
+
```
15
+
16
+
While effective, using Object.assign() can quickly make simple reducers difficult to read given its rather verbose syntax.
17
+
18
+
An alternative approach is to use the object spread syntax recently added to the JavaScript specification. It lets you use the spread (...) operator to copy enumerable properties from one object to another in a more succinct way. The object spread operator is conceptually similar to the ES6 array spread operator. We can simplify the todoApp example above by using the object spread syntax:
The advantage of using the object spread syntax becomes more apparent when you're composing complex objects. Below getAddedIds maps an array of id values to an array of objects with values returned from getProduct and getQuantity.
0 commit comments