I have a function defined in my component class which is calling it's parent function where that child is being utilized.
completeSession(id) {
this.props.completeSession(id);
}
This function calls the parent function with id. The parent function is:
completeSession(id) {
console.log("Entered parent complete Session");
console.log(id);
this.setState({feedback_id: id});
console.log(this.state.feedback_id);
}
Here as you can see I have 3 console logs and my console.log(id) is giving a proper value but this.state.feedback_id comes as undefined. Over here the this.setState should update feedback_id and this should update the child component also.
renderPast() {
return(
<PastSessions timezone={this.state.timezone}
feedback_id={this.state.feedback_id}
sessions={this.state.sessions}
completeSession={this.completeSession.bind(this)}
cancelSession={this.cancelSession.bind(this)} />
)
}
So I'm passing the feedback id back to the component so I'm not sure why it is not setting the state as intended. Any help would be appreciated.
Please keep in mind that setState is asynchronous - so state is not updated immidiately after calling it. You can provide a callback function as setState second argument which will be called when the state is actually updated:
this.setState({feedback_id: id}, () => {
console.log('state updated');
console.log(this.state.feedback_id);
});
According to React setState documentation:
... the second parameter is an optional callback function that will be
executed once setState is completed and the component is re-rendered.
Generally we recommend using componentDidUpdate() for such logic
instead.
setState() does not immediately mutate this.state but creates a
pending state transition. Accessing this.state after calling this
method can potentially return the existing value.
Related
I am trying to execute the parent function by calling it from child component and it does not yield proper results. There is a Pagination Component that computes the offsets for the pagination and sends the data to the child by calling parents method.
Console log statement inside Parent gives wrong result where as inside child's setOffSet() gives proper result and when sent to parent component's method in the next line, It gives wrong result.
Code Sandbox: https://codesandbox.io/s/react-typescript-v91un
setState needs a callback function but you're immediately calling the handlePagination function so you'd be passing in the return value of handlePagination. Try this instead...
this.setState(
{ fromIndex },
() => this.props.handlePagination(this.state.fromIndex, NO_OF_RECORDS_PER_PAGE)
);
Why is using componentDidUpdate more recommended over the setState callback function (optional second argument) in React components (if synchronous setState behavior is desired)?
Since setState is asynchronous, I was thinking about using the setState callback function (2nd argument) to ensure that code is executed after state has been updated, similar to then() for promises. Especially if I need a re-render in between subsequent setState calls.
However, the official React Docs say "The second parameter to setState() is an optional callback function that will be executed once setState is completed and the component is re-rendered. Generally we recommend using componentDidUpdate() for such logic instead."
And that's all they say about it there, so it seems a bit vague. I was wondering if there was a more specific reason it is recommended to not use it? If I could I would ask the React people themselves.
If I want multiple setState calls to be executed sequentially, the setState callback seems like a better choice over componentDidUpdate in terms of code organization - the callback code is defined right there with the setState call. If I use componentDidUpdate I have to check if the relevant state variable changed, and define the subsequent code there, which is less easy to track. Also, variables that were defined in the function containing the setState call would be out of scope unless I put them into state too.
The following example might show when it might be tricky to use componentDidUpdate:
private functionInComponent = () => {
let someVariableBeforeSetStateCall;
... // operations done on someVariableBeforeSetStateCall, etc.
this.setState(
{ firstVariable: firstValue, }, //firstVariable may or may not have been changed
() => {
let secondVariable = this.props.functionFromParentComponent();
secondVariable += someVariableBeforeSetStateCall;
this.setState({ secondVariable: secondValue });
}
);
}
vs
public componentDidUpdate(prevProps. prevState) {
if (prevState.firstVariableWasSet !== this.state.firstVariableWasSet) {
let secondVariable = this.props.functionFromParentComponent();
secondVariable += this.state.someVariableBeforeSetStateCall;
this.setState({
secondVariable: secondValue,
firstVariableWasSet: false,
});
}
}
private functionInComponent = () => {
let someVariableBeforeSetStateCall = this.state.someVariableBeforeSetStateCall;
... // operations done on someVariableBeforeSetStateCall, etc.
this.setState({
firstVariable: firstValue,
someVariableBeforeSetStateCall: someVariableBeforeSetStateCall,
firstVariableWasSet: true });
//firstVariable may or may not have been changed via input,
//now someVariableBeforeSetStateCall may or may not get updated at the same time
//as firstVariableWasSet or firstVariable due to async nature of setState
}
Also, apart from componentDidUpdate being generally recommended, in what cases would the setState callback be more appropriate to use?
Why is using componentDidUpdate more recommended over the setState callback function?
1. Consistent logic
When using the callback argument to setState(), you might have two separate calls to setState() in different places which both update the same state, and you'd have to remember to use the same callback in both places.
A common example is making a call to a third-party service whenever a piece of state changes:
private method1(value) {
this.setState({ value }, () => {
SomeAPI.gotNewValue(this.state.value);
});
}
private method2(newval) {
this.setState({ value }); // forgot callback?
}
This is probably a logic error, since presumably you'd want to call the service any time the value changes.
This is why componentDidUpdate() is recommended:
public componentDidUpdate(prevProps, prevState) {
if (this.state.value !== prevState.value) {
SomeAPI.gotNewValue(this.state.value);
}
}
private method1(value) {
this.setState({ value });
}
private method2(newval) {
this.setState({ value });
}
This way, the service is guaranteed to be called whenever the state updates.
Additionally, state could be updated from external code (e.g. Redux), and you won't have a chance to add a callback to those external updates.
2. Batched updates
The callback argument of setState() executes after the component is re-rendered. However, multiple calls to setState() are not guaranteed to cause multiple renders, due to batching.
Consider this component:
class Foo extends React.Component {
constructor(props) {
super(props);
this.state = { value: 0 };
}
componentDidUpdate(prevProps, prevState) {
console.log('componentDidUpdate: ' + this.state.value);
}
onClick = () => {
this.setState(
{ value: 7 },
() => console.log('onClick: ' + this.state.value));
this.setState(
{ value: 42 },
() => console.log('onClick: ' + this.state.value));
}
render() {
return <button onClick={this.onClick}>{this.state.value}</button>;
}
}
We have two setState() calls in the onClick() handler, each simply prints the new state value to the console.
You might expect onClick() to print the value 7 and then 42. But actually, it prints 42 twice! This is because the two setState() calls are batched together, and only cause one render to occur.
Also, we have a componentDidUpdate() which also prints the new value. Since we only have one render occurring, it is only executed once, and prints the value 42.
If you want consistency with batched updates, it's usually far easier to use componentDidMount().
2.1. When does batching occur?
It doesn't matter.
Batching is an optimization, and therefore you should never rely either on batching occurring or it not occurring. Future versions of React may perform more or less batching in different scenarios.
But, if you must know, in the current version of React (16.8.x), batching occurs in asynchronous user event handlers (e.g. onclick) and sometimes lifecycle methods if React has full control over the execution. All other contexts never use batching.
See this answer for more info: https://stackoverflow.com/a/48610973/640397
3. When is it better to use the setState callback?
When external code needs to wait for the state to be updated, you should use the setState callback instead of componentDidUpdate, and wrap it in a promise.
For example, suppose we have a Child component which looks like this:
interface IProps {
onClick: () => Promise<void>;
}
class Child extends React.Component<IProps> {
private async click() {
await this.props.onClick();
console.log('Parent notified of click');
}
render() {
return <button onClick={this.click}>click me</button>;
}
}
And we have a Parent component which must update some state when the child is clicked:
class Parent extends React.Component {
constructor(props) {
super(props);
this.state = { clicked: false };
}
private setClicked = (): Promise<void> => {
return new Promise((resolve) => this.setState({ clicked: true }, resolve));
}
render() {
return <Child onClick={this.setClicked} />;
}
}
In setClicked, we must create a Promise to return to the child, and the only way to do that is by passing a callback to setState.
It's not possible to create this Promise in componentDidUpdate, but even if it were, it wouldn't work properly due to batching.
Misc.
Since setState is asynchronous, I was thinking about using the setState callback function (2nd argument) to ensure that code is executed after state has been updated, similar to .then() for promises.
The callback for setState() doesn't quite work the same way as promises do, so it might be best to separate your knowledge.
Especially if I need a re-render in between subsequent setState calls.
Why would you ever need to re-render a component in between setState() calls?
The only reason I can imagine is if the parent component depends on some info from the child's DOM element, such as its width or height, and the parent sets some props on the child based on those values.
In your example, you call this.props.functionFromParentComponent(), which returns a value, which you then use to compute some state.
Firstly, derived state should be avoided, since memoization is a much better option. But even so, why not just have the parent pass the value directly down as a prop? Then you can at least compute the state value in getDerivedStateFromProps().
//firstVariable may or may not have been changed,
//now someVariableBeforeSetStateCall may or may not get updated at the same time
//as firstVariableWasSet or firstVariable due to async nature of setState
These comments don't make much sense to me. The asynchronous nature of setState() doesn't imply anything about state not getting properly updated. The code should work as intended.
I have a property name in a React component. Using setState I am trying to modify this property. But assigning a new value to this property inside setState has no effect. Please find below my sample code.
export const Test = ({
name,
changeState = function (newName) {
this.setState({name: newName}, () => console.log('Name after setState # ' + name)); //prints old value
console.log(name); // Doesn't reflect changes. Prints old name
}
}) =>
(
<div>Some data</div>
)
User action will trigger a call to changeState(newName). I am calling setState inside changeState function.
After calling setState if I print the name variable to console it still holds old value.
How can I make setState assign a new value to name?
I am aware that setState is asynchronous and update to property may reflect after a delay. But in case of example code above name variable is never updated even after a delay.
I have implemented componentWillReceiveProps(nextProps) method and it gets called but it always receives old name. So I don't think the issue is related to setState being asynchronous.
I have created an example app to demonstrate the issue I am facing. The example app runs fine locally and I can reproduce the issue. But I am not being able to get the same example app code working in codepen. it's giving me some 'unexpected token' errors. But I hope looking at the code will help understand my issue better. The code is based on existing application structure.
Codepen example here.
In the code I have a Parent and two children Child1 and Child2. In Parent I have a function changeState defined which I am passing to Child1 as property. And to Child2 I am passing a 'name' property from Parent.
Clicking on 'Change Name' button in Child1 triggers a call to changeState function of Parent. Initial value of name in Parent is 'Robert'. changeState is invoked from Child1 with new name value of 'Tom'. But in changeState function assigning new value to 'name' using setState has no effect. I am calling a function to print the 'name' after setState has completed but it prints old name value and NOT the new one assigned in setState.
You are using stateless component, there's for, there is no state so the setState function doesn't affect anything.
there are 2 options to deal with it:
the easiest one, but most likely not the best option, just change your component to regular component:
export class Test1 extends React.componnent {
...
(the rest of your component)
}
the second option (usually a better one in my option) is instead of changing the state for the component, get an event from the parent component, and call the event where you wanted to call the setState, the event would contain an updating the value as requested, and the child component would receive it as prop, and your component wouldn't have to change to Container (a component with state)
Good luck!
I need to set state and run a function on a onClick event. How do I accomplish this in React?
I've atttempted to put these two things in their own function, but that give me this warning below.
Warning: setState(...): Cannot update during an existing state transition (such as within render or another component's constructor). Render methods should be a pure function of props and state; constructor side-effects are an anti-pattern, but can be moved to componentWillMount.
editLink(onEditLink, link) {
this.setState({showContent: false});
onEditLink(link);
}
render() {
return (
<a onClick={this.editLink(this.props.onEditLink, this.props.link)}>Edit</a>
)
}
The problem is you are calling the function right away instead of assigning a new function which will be executed when the element is clicked:
editLink(onEditLink, link) {
this.setState({showContent: false});
onEditLink(link);
}
render() {
return (
<a onClick={() => this.editLink(this.props.onEditLink, this.props.link)}>Edit</a>
)
}
What you want to do is pass a function, which when executed, will call your this.editLink function with those parameters.
setState accepts a callback function as its second argument, I suggest you utilize that:
editLink(onEditLink, link) {
this.setState({showContent: false}, () => {
onEditLink(link);
});
}
The second parameter to setState() is an optional callback function
that will be executed once setState is completed and the component is
re-rendered. Generally we recommend using componentDidUpdate() for
such logic instead.
Answer:
I'm a bonehead. This is way late but don't want to leave a thread unanswered and especially since my initial answer was wrong. I needed to reference the new props I was getting, not this.props. As usual the answer was in the documentation. I updated my own answer below to reflect this.
Edit 1:
My first fiddle did not fully show my issue so I've updated it to demonstrate better. For some reason when I call my setState() I believe the first pass through it is undefined even though its given a value, yet on subsequent passes it works as expected. It seems like my initial setState() call is not triggering a rerender but all others are.
A bit different to the usual "setState not updating view" question as setState() IS updating my view and with the correct value. Just not when I expect it to. Basically I am triggering a setState() event should rerender my child component with new props which I believe should trigger the childs components componentWillReceiveProps lifecyle event, which will then call setState() within the child component and update its view. The issue is while it does update the view, it seems to do it a cycle behind when expected. In my MVP I call setState() at 2 seconds yet it updates the view at 4 seconds. I haven't been able to determine which part is the bad logic though.
Here is my jsFiddle MVP. Thanks for any suggestions.
Code:
class TaskBody extends React.Component {
constructor(props) {
super(props);
this.state = {};
}
componentWillReceiveProps() {
this.setState({
activeTask: this.props.activeTask
});
}
render() {
return <div>
< h4 > {
this.state.activeTask ? this.state.activeTask : 'Task Title'
} < /h4>
< /div > ;
}
}
class Body extends React.Component {
constructor(props) {
super(props);
this.state = {
activeTask: '',
counter: 1
};
this.updateActive = this.updateActive.bind(this);
}
updateActive(task) {
this.setState({
activeTask: task
});
}
componentDidMount(){
var self = this;
setInterval(function(){
if(self.state.counter === 4){
clearInterval(self.clickInterval);
return clearInterval(self.countInterval);
}
self.setState({ counter: self.state.counter + 1 });
}, 1000);
// imagine this was the click event, it should rerender the view
// instantaneously at 2 seconds because I called setState() right?
// which is supposed to trigger a re-render and then TaskBody should
// receive new props triggering it to setState() on its activeTask,
// which should update the view?
self.clickInterval = setInterval(function(){
self.setState({ activeTask: 'took double the time it should' });
}, 2000);
}
render() {
return <div>
< TaskBody activeTask = {
this.state.activeTask
}/>
<div>{this.state.counter}</div>
</div>;
}
}
ReactDOM.render(<Body />, document.querySelector('#body'));
The
self.setState({ activeTask: 'took double the time it should' });
is never actually called.
Here's why:
Your logic is located within the componentDidMount lifecycle method. If you read the documentation of componentDidMount, you'll see that it clearly states:
Invoked once, only on the client (not on the server), immediately
after the initial rendering occurs.
So, when componentDidMount gets called in your app, you're first checking the counter and calling a setState there. That alone will trigger a new render. This means that your second code block within componentDidMount is going to have no effect because while you set the method, it's never going to get called anywhere.
In my old answer, I was using a setTimeout() as a hack to get the results I wanted. Basically, if I wrapped my setState in a timeout it would set the state with the new props, but if I did not it would still reference the old props. Fortunately, this is already handled in react as componentWillReceiveProps already receives a newProps argument by default.
This:
componentWillReceiveProps(){
var self = this;
setTimeout(function(){
self.setState({activeTask: self.props.activeTask});
},0);
}
becomes
componentWillReceiveProps(newProps){
var self = this;
self.setState({activeTask: newProps.activeTask});
}