Let's say I have two Components. The parent is passed an Object as a property, which it then copies into local data store. It has a function to update this local store, which gets passed down to a child. Here is my parent Component:
const Parent = ({stuff}) => {
const store = {
stuff: Object.assign({}, stuff);
}
const updateStuff = (thing, property) => store.stuff[thing].property = thing;
return <Child stuff={stuff} updateStuff={updateStuff} />
}
The Child Component has a similar structure -- it makes a copy of stuff, and mutates its copy of stuff on an <input>'s onChange. It then passes its own updated copy of stuff to the updateStuff function it received, in order to mutate the Parent's copy of the prop. Here is the Child.
const Child = ({stuff, updateStuff}) => {
const stuff = {
thing1: Object.assign({}, stuff.thing1),
thing2: Object.assign({}, stuff.thing2)
}
const setProp = event => {
const update = event.target.value;
stuff.thing1.prop = update;
updateStuff(thing1, stuff.thing1.prop)
}
return (
<div>
<input id="thing1" onChange={setProp} />
<input id="thing1" onChange={setProp} />
</div>
)
}
Notice, I've used Object.assign to basically clone the stuff prop or its child properties, as the case necessitates. The reason for this: a React prop is read-only, and thus I need to create a clone to make changes on before passing it back to mutate the app's state (not shown here)/
Now, this works on the Child component -- setProp mutates the correct property of stuff, confirmed by logging to the console. However, when the method gets to updateTeam, I get an error message : Uncaught TypeError: Cannot assign to read only property 'side' of object '#<Object>'
Yet, both Components use the same principle: I am not mutating the prop, but rather I am mutating a locally-stored clone of the prop. Why does this work for Child, but not for Parent?
Object.assign only does a shallow copy of the prop Object.assign Reference. In order to make a true deep copy of the prop (and get rid of the error) you can do a deep copy with newStuff: JSON.parse(JSON.stringify(stuff)). Glad this helped!
The real reason behind this is given in an example:
let original = {
name: 'Test',
nestedObj: {
(...some properties)
}
}
In the example above, the original object property 'name' is a new copy but the nested object is still a reference to the original. This way when you try and edit the part of the nested object it references the original and yells that it is immutable.
Try changing const to let for your local copies
Related
In react, specifically referencing the hooks/functional paradigm, when do you need to use props.functionName? As far as I can tell, if the functions are named the same, you can omit props as follows:
Parent.js
...
<Child functionName={functionName}/>
...
Child.js
...
functionName();
...
However, if the name changes, props must be referenced as follows:
Parent.js
...
<Child otherName={functionName}/>
...
Child.js
...
props.otherName();
...
Am I correct? If so, why use the second design pattern? (Perhaps just to call out that the function comes from a parent and isn't defined at the child level. Or maybe some other reason?)
No. The name you use depends entirely on how the child component processes the props it is passed. How the parent component determines what value to pass is completely irrelevant.
If the props are placed in a variable named props then you need to access them through the object stored in the variable.
const Child = (props) => {
props.functionName();
...
}
If the first argument is destructured, then each property is stored in its own variable.
const Child = ({functionName}) => {
functionName();
...
}
If the value is copied to another variable inside the component then you can also use the variable it was copied to.
const Child = (props) => {
const functionName = props.functionName();
functionName();
...
}
False, It is Destructuring Props in React;
Destructuring is a convenient way of extracting multiple values from data stored in (possibly nested) objects and Arrays
props is an object so we can use the Destructuring
Destructuring gives access to the use of props in a more readable format and discards the need for props for every property.
<Child functionName={functionName} name={name}/>;
const child = (props)=>{
// you need to write props.functionName
props.functionName();
const thisName = props.name
};
const child =({functionName,name})=>{
// you dont need to write *props.*
functionName();
const thisName = name
};
When interfacing with a child component, the name that you use for something in your parent component may be different from the prop that the child component requires.
Just for example, say that your parent component has something to do with school, and you have:
const [studentId, setStudentId] = useState();
const [parentId, setParentId] = useState();
But you also have a child component for students that expects an id prop. Then, to pass down the studentId to it, you'd do:
<Student id={studentId} />
And in that child component, you'd reference it by doing props.id.
You wouldn't want to do
const [id, setId] = useState();
in the parent component, and then
<Student id={id} />
when passing it down because then it wouldn't be clear in the parent component which ID that stateful value referred to - you'd probably have to add a comment.
If so, why use the second design pattern?
Sometimes, like in the situation I just described, the child component isn't designed with all identifiers used in the parent component in mind - which is perfectly reasonable, that's what allows for so many things in programming to be modular (and adaptable and useful). As a result, sometimes you need a prop or variable to have one name in the parent component, and another in the child component, which requires the
<Child otherName={functionName}/>
approach.
I'm rendering a list based on an object. I'm adding new elements to this object by help of the mutations. When I log this.$store.state.myObject to console, I can see that it is updating. However, my list is not updated.
Actually, I got lucky and I fixed this issue by adding the line of code below in my mutation. (I found out that this can help DOM update.)
But I'd like to learn if this is a good solution.
state.realms = Object.assign({}, state.realms)
Here is my whole mutation:
addToRealms: (state, val) => {
var id = val.id
var realmName = val.name.en_US
state.realms[id] = { name: realmName }
state.realms = Object.assign({}, state.realms)
}
And here is my vue page code
<q-btn flat
v-for="(realm,code) in realms"
:key="code"
#click="selectRealm(realm)"
:label="realm.name"
clickable/>
I defined realms as a computed property.
computed: {
realms () {
return this.$store.state.realms
}
Further info:
I use vue.js devtools extension, when I track my commit on vuex store I can see that I'm really changing the state. But It doesnt affect immediately. If I press commit all button, my list gets updated.
Thanks.
When you use
state.realms = Object.assign({}, state.realms)
you basically are recreating a new object based on the previous one (breaking the references in case there are not nested objects), and that's the reason why in this way the list get updated.
Give a read to this article to understand more about deep-cloning and breaking references.
The Object.assign() method is used to copy the values of all enumerable own properties from one or more source objects to a target object
When you add new properties to the object, those are not reactive. To make them reactive, use the Vue.set() method, (docs here).
Vue.set(state.realms[id],'name', realmName);
I am receiving props in my component. I want to add a property 'LegendPosition' with the props in this component. I am unable to do that. Please help me with this.
I have tried this code yet but no success:
var tempProps = this.props;
tempProps.legendPosition = 'right';
Object.preventExtensions(tempProps);
console.log(tempProps);
You can't modify this.props. Here tempProps is reference of this.props so it does not work. You should create a copy of the props using JSON.parse() and JSON.stringify()
var tempProps = JSON.parse(JSON.stringify(this.props));
tempProps.legendPosition = 'right';
Object.preventExtensions(tempProps);
console.log(tempProps);
For a better and efficient way to deep clone object see What is the most efficient way to deep clone an object in JavaScript?
props is not mutable, you cant "add" anything to them. if you want to "copy" them then you need to do
const tempProps = {...this.props};
And the only reason i can see you needing to add more props is to pass it down to a child, but you can do that without adding it to the props object.
EDIT: add props with extra prop
<Component {...this.props} legendPosition="right" />
I want to send the updated props to a child component, If it is possible without copying or cloning to a new object, Please help me how can I achieve this.
Solution is as simple as:
<ChildComponent {...this.props} legendPosition="right" />
Of course legendPosition will be available in ChildComponent by this.props.legendPosition.
Of course earlier this.props can contain already legendPosition property/value which will be overwritten by defined later - order matters.
Of course there can be many spread operators - for multiple properties, logic blocks ... whatever:
const additonalProps = {
legendPosition: 'right',
sthElse: true
}
return (
<ChildComponent {...this.props} {...additonalProps} />
)
below in tempProps object spread operator copy your this.props object and after spread operator we can add new object property or we can update existing object property.
var tempProps = {
...this.props,
tempProps.legendPosition = 'right' //property you want to add in props object
};
Your answer is in this line.
var tempProps = this.props;
this.props is immutable that means you can not change the property value in function.
you can use a this.state so you can modify it in your function
props --- you can not change its value.
states --- you can change its value in your code, but it would be active when a render
happens.
For anyone getting this error with jest, make sure to mock your component this way:
jest.mock('component/lib', () => ({
YourComponent: jest.fn()
}))
Then in your test you can mock the implementation:
(YourComponent as jest.Mock).mockImplementation(() => <div>test</div>);
Hope this works
You can define default values for your props properly by assigning to the special defaultProps property:
https://reactjs.org/docs/typechecking-with-proptypes.html
class Greeting extends React.Component {
render() {
return <h1>Hello, {this.props.name}</h1>;
}
}
// Specifies the default values for props:
Greeting.defaultProps = {
name: 'Stranger',
};
My code works, but I have a best practice question: I have an array of objects in the state, and a user interaction will change a value of one object at a time. As far as I know, I'm not supposed to change the state directly, i should always use setState instead. If I want to avoid that with any price, I will deep clone the array by iteration, and change the clone. Then set the state to the clone. In my opinion avoiding to change the state that I will change later anyway is just decreasing my performance.
Detailed version:
this.state.data is an array of objects. It represents a list of topics in a forum, and a Favorite button will toggle, calling clickCollect().
Since I have an array in the state, when I change the is_collected property of one item, I need to create a copy of the array to work with, and after changing to the new value, I can set it to the state.
var data = this.state.data.slice(0);
data[index].is_collected = !data[index].is_collected;
this.setState({data: data});
var data = this.state.data : This would copy the pointer to the array and push(), shift(), etc would alter the state directly. Both data and this.state.data will be affected.
var data = this.state.data.slice(0) : This makes a shallow clone, push and shift doesn't change the state but in my clone I still have pointers to the elements of the state's array. So if I change data[0].is_collected, this.state.data[0].is_collected gets changed as well. This happens before I call setState().
Normally I should do:
var data = [];
for (var i in this.state.data) {
data.push(this.state.data[i]);
}
Then I change the value at index, setting it to true when it's false or false when it's true:
data[index].is_collected = !data[index].is_collected;
And change state:
this.setState({data: data});
Consider my array is relatively big or enormously big, I guess this iteration will reduce the performance of my APP. I would pay that cost if I knew that it is the right way for any reason. However, in this function (clickCollect) I always set the new value to the state, I'm not waiting for a false API response that would say to stop making the change. In all cases, the new value will get into the state. Practically I call setState only for the UI to render again. So the questions are:
Do I have to create the deep clone in this case? (for var i in ...)
If not, does it make sense to make a shallow clone (.slice(0)) if my array contains objects? The changes are being made on the objects inside of the array, so the shallow clone still changes my state, just like a copy (data = this.state.data) would do.
My code is simplified and API calls are cut out for simplicity.
This is a beginner's question, so a totally different approach is also welcome. Or links to other Q & A.
import React from 'react';
var ForumList = React.createClass({
render: function() {
return <div className="section-inner">
{this.state.data.map(this.eachBox)}
</div>
},
eachBox: function(box, i) {
return <div key={i} className="box-door">
<div className={"favorite " + (box.is_collected ? "on" : "off")} onTouchStart={this.clickCollect.bind(null, i)}>
{box.id}
</div>
</div>
},
getInitialState: function() {
return {data: [
{
id: 47,
is_collected: false
},
{
id: 23,
is_collected: false
},
{
id: 5,
is_collected: true
}
]};
},
clickCollect: function(index) {
var data = this.state.data.slice(0);
data[index].is_collected = !data[index].is_collected;
this.setState({data: data});
}
});
module.exports = ForumList;
Personally I don't always follow the rule, if you really understand what you are trying to do then I don't think it's a problem.
var data = this.state.data.slice(0);
data[index].is_collected = !data[index].is_collected;
this.setState({data: data});
In this case, mutating state and calling the setState again like this is fine
this.state.data[index].is_collected = !this.state.data[index].is_collected;
this.setState({data: this.state.data});
The reason you should avoid mutating your state is that if you have a reference to this.state.data, and calling setState multiple times, you may lose your data:
const myData = this.state.data
myData[0] = 'foo'
this.setState({ data: myData })
// do something...
// ...
const someNewData = someFunc()
this.setState({ data: someNewData })
myData[1] = 'bar' // myData is still referencing to the old state
this.setState({ data: myData }) // you lose everything of `someNewData`
If you really concerned about this, just go for immutable.js
Muting the state directly breaks the primary principle of React's data flow (which is made to be unidirectional), making your app very fragile and basically ignoring the whole component lifecycle.
So, while nothing really stops you from mutating the component state without setState({}), you would have to avoid that at all costs if you want to really take advantage of React, otherwise you would be leapfrogging one of the library's core functionalities.
If you want follow react best practices, you should do shallow copy of all your array, when you change any property. Please look into "immutable" library implementation.
But, from my experience, and from my opinion, setState method should be called if you have "shouldCompomenentUpdate" implementations. If you think, that your shallow copy will be consume much more resources, then react virtual dom checks, you can do this:
this.state.data[0].property = !this.state.data[0].property;
this.forceUpdate();
If I understood your question right, you have an array of objects and when a property of a single object in array changes,
Create a deep clone of the array and pass to setState
Create a shallow clone and pass to setState
I just checked with the redux sample todo app and in case of a single property of an object changes you've to create a fresh copy of that single object not the entire array. I recommend you to read about redux and if possible use to manage the state of your app.
When i create several instances of a react class (by using React.createElement on the same class), some member variables are shared between the instances (arrays and objects are shared, strings and booleans etc. not).
For me this feels horrible and scary and wrong. Is this a bug or is there another way to do what i want to do?
Please have a look:
http://jsbin.com/kanayiguxu/1/edit?html,js,console,output
What you should be doing is setting state on your component, instead of having state as arbitrary properties on your React component.
So instead of doing this:
var MyComponent = React.createClass({
myArray: [1, 2, 3],
componentWillMount() {
this.myArray.push(this.myArray.length + 1);
},
render() {
return (
<span>{this.myArray.length}</span>
);
}
});
You should be doing this:
var MyComponent = React.createClass({
getInitialState() {
return {
myArray: [1, 2, 3]
};
},
componentWillMount() {
this.setState(state => {
state.myArray.push(state.myArray.length + 1);
return state;
});
},
render() {
return (
<span>{this.myArray.length}</span>
);
}
});
The reason being that all of a components state and data should reside in this.state and this.props which is controlled and handled by React.
The benefit you get from using props and state for this, is that React will know when those change, and from that it can tell when it's time to re-render your component. If you store state as arbitrary properties or globals, React won't know when those change, and cannot re-render for you.
The reason for the behaviour you're seeing is that every instance of the component uses the object you give to React.createClass() as its prototype. So all instances of the component has a myArray property, but that is on the prototype chain, and thus shared by all instances.
If you truly want something like this and you want to avoid this.state, you should use something like componentWillMount and inside that method, assign properties to this. This will make sure that such data is only on that particular instance, and not on the prototype chain.
EDIT
To even further clearify, it can be good to know that the object passed to React.createClass() isn't the actual object on the prototype. What React does is that it iterates over all properties on that object, and copies them onto the prototype of the React element object. This can be illustrated by this example:
var obj = {
myArray: [1, 2, 3],
title: 'My title',
componentWillMount() {
this.myArray.push(this.myArray.length + 1);
},
render() {
return (
<span>{this.myArray.length}</span>
);
}
}
var MyComponent = React.createClass(obj);
// This doesn't change the component, since 'obj' isn't used anymore
// by React, it has already copied all properties.
obj.title = 'New title';
// This however affects the component, because the reference to the array
// was copied to the component prototype, and any changes to what the
// reference points to will affect everyone who has access to it.
obj.myArray.push(666);