I have two basic questions about React:
In order to assign an initial empty value to a piece of state (let's say player) in a functional component, are the following two approaches the same or are they different in some way?
Approach A:
const [player, setPlayer] = useState({})
Approach B:
useEffect(() => {
setPlayer({})
}, []);
When I browse to a player, the page is eventually updated with values coming from the global store so I need to avoid showing the values of the previous player while the current one is still loading. What is the best way to go about this?
Please let me know if you need more background information in order to help.
Thank you in advance!
When assigning initial value directly in useState(initialData) you are making that state available in the very first render.
On the other hand, if you are setting the initial value in a useEffect hook, it will be set on mount, but after the very first render.
useEffect(() => {
setPlayer(initialData)
}, [])
If the state variable is important also for the first render, then you should use the first approach. It is also shorter to write and makes more sense.
Example:
if you open your devtools when running this example, the debugger will pause inside the useEffect and you will see nothing will be rendered ("mount" phase), which might not be desirable. If you were to edit the code and write useState(initialData), you would see the first render did include the correct state when the (when debugger pauses code execution).
const {useState, useEffect} = React
const App = ({initialData}) => {
const [value, setValue] = useState('🔴')
useEffect(() => {
debugger; // at this point, the component has already been rendered
setValue(initialData)
}, [])
return value
}
ReactDOM.render(<App initialData={'🟢'} />, root)
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/16.10.0/umd/react.production.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/16.10.0/umd/react-dom.production.min.js"></script>
<div id='root'></div>
Related
I was wondering if using useState in React just to set value once is considered a good practice and if not, how can it be improved.
Let's say that I have a simple component, that just fetches some data and displays them in a dropdown:
import React, {useState, useEffect} from 'react';
import {utilities} from './utils';
const Component = (props) => {
const [ingredients, setIngredients] = useState([]);
useEffect(() => {
new Promise((resolve, reject) => {
const res = utilities.getIngredients();
if (res.data) {
resolve("Stuff worked!");
}
else {
reject(Error("It broke"));
}
}).then((response) => {
setIngredients(response);
});
}, []);
return (
<div>
<p>Choose from possible ingredients:</p>
<Select options={ingredients}/>
</div>
);
}
export default Component;
Since setIngredients is only called once, is it not too much to use useState here? My intuition tells me that there might be a better way to do it. On the other hand when I tried just using a variable, then the values wewe not updated and dropdown was not showing any options (what makes sense, since data arrived after the dropdown was rendered).
Can you please judge what could be improved here?
State is used when persistence across renders is needed. If your component is re-rendered (React to decides when this happens), unsettled Promises (like the ones used by Axios or in the example in your question) will still settle and can assign values to variables - but those variables don't really exist any more. When a Function Component is rerendered, any declared variable is initialised as if this was the first run of the Function Component (it really is just a function). Any reference to a "plain" variable (declared the traditional way let, const or var, rather than by React Hooks) held by the Promise will no longer be the same variable used by the Function Component on the next run.
Here's an example to illustrate:
const Component = (props) => {
let nonStateIngredients = []; //will get initialised to [] every render
useEffect(() => {
doSomethingThatTakesAWhile()
.then((response) => {
// If the Component has been re-rendered
// by the time we get here, the next line will not
// do anything
nonStateIngredients = response.ingredients;
// If not, the above line will work,
// but as soon as we rerender, it will be reinitialised
// to []
});
}, []);
Anything that is not part of a React Hook will essentially be re-initialised.
So, in React, we use:
"Plain" (let, const) variables to store data is derived from existing State or Props within a render, or is constant for the lifetime of the Component
State to store data that must persist across renders (data that can change over time)
Memos (or Memoized variables) to store data that is always derived, but is expensive (takes a lot of processing power) to derive (this is an optimisation of a "plain" variable)
To answer your question more directly, when we use State to retrieve and assign a value, it's not best practice - it's the only thing that works.
NB: I've asked this on wordpress.stackexchange, but it's not getting any response there, so trying here.
I'm not sure if this is WordPress specific, WordPress's overloaded React specific, or just React, but I'm creating a new block plugin for WordPress, and if I use useState in its edit function, the page is re-rendered, even if I never call the setter function.
import { useState } from '#wordpress/element';
export default function MyEdit( props ) {
const {
attributes: {
anAttribute
},
setAttributes,
} = props;
const [ isValidating, setIsValidating ] = useState( false );
const post_id = wp.data.select("core/editor").getCurrentPostId();
console.log('Post ID is ', post_id);
const MyPlaceholder = () => {
return(
<div>this is a test</div>
);
};
const Component = MyPlaceholder;
return <Component />;
}
If I comment out const [ isValidating, setIsValidating ] = useState( false ); then that console.log happens once. If I leave it in, it happens twice; even if I never check the value of isValidating, never mind calling setIsValidating. I don't want to over-optimize things, but, equally, if I use this block n times on a page, the page is getting rendered 2n times. It's only on the admin side of things, because it's in the edit, so maybe not a big deal, but ... it doesn't seem right. Is this expected behavior for useState? Am I doing something wrong? Do I have to worry about it (from a speed perspective, from a potential race conditions as everything is re-rendered multiple times)?
In your example code, the console.log statement is being immediately evaluated each time and triggering the redraw/re-rendering of your block. Once console.log is removed, only the state changes will trigger re-rendering.
As the Gutenberg Editor is based on Redux, if the state changes, any components that rely on that state are re-rendered. When a block is selected in the Editor, the selected block is rendered synchronously while all other blocks in the Editor are rendered asynchronously. The WordPress Gutenberg developers are aware of re-rendering being a performance concern and have taken steps to reduce re-rendering.
When requesting data from wp.data, useEffect() should be used to safely await asynchronous data:
import { useState, useEffect } from '#wordpress/element';
export default function MyEdit(props) {
...
const [curPostId, setCurPostId] = useState(false);
useEffect(() => {
async function getMyPostId() {
const post_id = await wp.data.select("core/editor").getCurrentPostId();
setCurPostId(post_id);
}
getMyPostId();
}, []); // Run once
const MyPlaceholder = () => {
return (
<div>Current Post Id: {curPostId}</div>
);
};
const Component = MyPlaceholder;
return <Component />;
}
As mentioned in the question, useState() is used in core blocks for setting and updating state. The state hook was introducted in React 16.8, its a fairly recent change and you may come across older Gutenberg code example that set state via the class constructor and don't use hooks.
Yes, you have to worry about always put an array of dependencies, so that, it won't re-render, As per your query, let's say are planning to edit a field here is the sample code
const [edit, setEdit]= useState(props);
useEffect(() => {
// logic here
},[edit])
that [edit] will check if there is any changes , and according to that it will update the DOM, if you don't put any [](array of dependencies) it will always go an infinite loop,
I guess this is expected behavior. If I add a similar console.log to native core blocks that use useState, I get the same effect. It seems that WordPress operates with use strict, and according to this answer, React double-invokes a number of things when in strict mode.
I'm going to introduce my question in two steps with slightly different code blocks in both.
Step 1:
Below we have a React application which renders itself every two seconds and therefore causes the browser to print render to the console. If the user presses any key, the renders will stop which in turn stops the console prints. Please ignore the line commented out for now.
import { useState, useEffect, useRef } from 'react';
function App() {
const [number, setUpdate] = useState(0);
const [isPaused, setIsPaused] = useState(false);
const intervalRef = useRef(undefined);
useEffect(() => {
intervalRef.current = setInterval(() => setUpdate(prevNumber => ++prevNumber), 2000);
window.addEventListener('keydown', handleKeyDown);
}, []);
const handleKeyDown = () => {
clearInterval(intervalRef.current);
console.log('console log here');
// setIsPaused(isPaused);
};
console.log('render');
return null;
};
export default App;
Here is a screenshot of the application:
What has happened above, is that I've let the component render five times and then I've pressed a key to stop the component from rendering.
Step 2:
In step 2 we have exactly the same application with the exception of not commenting out the state set in handleKeyDown.
const handleKeyDown = () => {
clearInterval(intervalRef.current);
console.log('console log here');
// This is no longer commented out. Why does it cause a new render?
setIsPaused(isPaused);
};
Here is a screenshot of the application with the code change made in step 2:
Again, I've let the component to render five times after I've pressed a key. But now there is an extra render even though the state should not be changing (because the state is not actually mutating because we set the same value as was already in the state) by setIsPaused(isPaused).
I'm having difficulty to understand what might the reason to cause the extra render at step 2. Maybe it's something obvious?
setIsPaused(isPaused) never causes a new render if I comment out the other state change which is run by setInterval which makes me even more baffled.
This is a known quirk, see #17474. It’s a side effect introduced by the new concurrent mode. The component function did re-run, but DOM will remain untampered.
I also found people post this interesting example. You can try exp with the code. The component function contains something like <div>{Math.random()}</div> although random number did changed in that extra re-run of the function, it wouldn’t reflect onto DOM if state isn’t changed.
Conclusion. You can consider this side effect harmless most of time.
U̶p̶d̶a̶t̶i̶n̶g̶ ̶a̶ ̶s̶t̶a̶t̶e̶ ̶n̶e̶v̶e̶r̶ ̶m̶e̶a̶n̶s̶ ̶D̶O̶M̶ ̶w̶i̶l̶l̶ ̶r̶e̶r̶e̶n̶d̶e̶r̶,̶ ̶y̶o̶u̶ ̶a̶r̶e̶ ̶r̶i̶g̶h̶t̶ ̶̶s̶e̶t̶I̶s̶P̶a̶u̶s̶e̶d̶(̶i̶s̶P̶a̶u̶s̶e̶d̶)̶̶ ̶w̶i̶l̶l̶ ̶n̶o̶t̶ ̶r̶e̶r̶e̶n̶d̶e̶r̶ ̶t̶h̶e̶ ̶D̶O̶M̶,̶ ̶b̶u̶t̶ ̶i̶t̶ ̶w̶i̶l̶l̶ ̶s̶e̶t̶ ̶t̶h̶e̶ ̶s̶t̶a̶t̶e̶ ̶a̶n̶d̶ ̶w̶i̶l̶l̶ ̶g̶i̶v̶e̶ ̶y̶o̶u̶ ̶t̶h̶e̶ ̶u̶p̶d̶a̶t̶e̶d̶ ̶v̶a̶l̶u̶e̶.̶ ̶(̶I̶ ̶a̶m̶ ̶c̶o̶n̶s̶i̶d̶e̶r̶i̶n̶g̶ ̶o̶n̶l̶y̶ ̶s̶t̶a̶t̶e̶ ̶w̶i̶t̶h̶ ̶f̶i̶e̶l̶d̶ ̶̶i̶s̶P̶a̶u̶s̶e̶d̶̶ ̶n̶o̶t̶h̶i̶n̶g̶ ̶e̶l̶s̶e̶)̶
Update: I did know this behavior existed until reading the accepted answer.
I have a component that's supposed to read a property from the component (which is either string "fill" or string "stroke") and pull the according key from an object to read it's context.
This gets mounted as soon as an object is selected, accesses the active object and pulls out it's color either as a fill color or a stroke color.
useEffect(() => {
setButtonColor(context.objects.getActiveObject()[props.type]);
}, []); //on mount
Mounting it like this:
<ColorPicker type="fill" />
<ColorPicker type="stroke" />
This supposed to run only once on mount. I thought when the dep array is empty, it runs on any case once when it's mounted.
So how do I run something once on mount utilizing props and context?
And why does it need a dependency at all when I want it to ALWAYS run only ONCE on mount, no matter what?
It's best to move away from the thinking that effects run at certain points in the lifecycle of a component. While that is true, a model that might help you better get to grips with hooks is that the dependency array is a list of things that the effect synchronizes with: That is, the effect should be run each time those things change.
When you get a linter error indicating your dependency array is missing props, what the linter is trying to tell you is that your effect (or callback, or memoization function) rely on values that are not stable. It does this because more often than not, this is a mistake. Consider the following:
function C({ onSignedOut }) {
const onSubmit = React.useCallback(() => {
const response = await fetch('/api/session', { method: 'DELETE' })
if (response.ok) {
onSignedOut()
}
}, [])
return <form onSubmit={onSubmit}>
<button type="submit">Sign Out</button>
</form>
}
The linter will issue a warning for the dependency array in onSubmit because onSubmit depends on the value of onSignedOut. If you were to leave this code as-is, then onSubmit will only be created once with the first value of onSignedOut. If the onSignedOut prop changes, onSubmit won't reflect this change, and you'll end up with a stale reference to onSignedOut. This is best demonstrated here:
import { render } from "#testing-library/react"
it("should respond to onSignedOut changes correctly", () => {
const onSignedOut1 = () => console.log("Hello, 1!")
const onSignedOut2 = () => console.log("Hello, 2!")
const { getByText, rerender } = render(<C onSignedOut={onSignedOut1} />)
getByText("Sign Out").click()
// stdout: Hello, 1!
rerender(<C onSignedOut={onSignedOut2} />)
getByText("Sign Out").click()
// stdout: Hello, 1!
})
The console.log() statement does not update. For this specific example that would probably violate your expectations as a consumer of the component.
Let's take a look at your code now.
As you can see, this warning is essentially stating that your code might not be doing what you think it is doing. The easiest way to dismiss the warning if you're sure you know what you're doing is to disable the warning for that specific line.
useEffect(() => {
setButtonColor(context.objects.getActiveObject()[props.type]);
// eslint-disable-next-line react-hooks/exhaustive-deps
}, []); //on mount
The correct way to do this would be to place your dependencies inside of the array.
const { type } = props
useEffect(() => {
setButtonColor(context.objects.getActiveObject()[type]);
}, [context, type]);
This would, however, change the button colour every time type changed. There's something to note here: You're setting state in response to props changing. That's called derived state.
You only want that state to be set on the initial mount. Since you only want to set this on the initial mount, you could simply pass your value to React.useState(initialState), which would accomplish exactly what you want:
function C({ type }) {
const initialColor = context.objects.getActiveObject()[type];
const [color, setButtonColor] = React.useState(initialColor);
...
}
This still leaves the problem that the consumer might be confused as to why the view does update when you change the props. The convention that was common before functional components took off (and one I still use) is to prefix props that are not monitored for changes with the word initial:
function C({ initialType }) {
const initialColor = context.objects.getActiveObject()[initialType];
const [color, setButtonColor] = React.useState(initialColor);
}
You should still be careful here, though: It does mean that, for the lifetime of C, it will only ever read from context or initialType once. What if the value of the context changes? You might end up with stale data inside of <C />. That might be acceptable to you, but it's worth calling out.
React.useRef() is indeed a good solution to stabilize values by only capturing the initial version of it, but it's not necessary for this use-case.
This is my workaround for the issue:
Set the color to a variable and then use that variable to set the button color on mount of the component.
const oldColor = useRef(context.objects.getActiveObject()[props.type]);
useEffect(() => {
setButtonColor(oldColor.current);
}, []); //on mount
useRef returns a mutable ref object whose .current property is
initialized to the passed argument (initialValue). The returned object
will persist for the full lifetime of the component.
I have Function Component that utilizes hooks. In the useEffect hook, I simply want to fetch data from my back end and store the results in state. However, despite adding the data variable as a dependency, useEffect still fires on an infinite loop - even though the data hasn't changed. How can I stop useEffect from firing continuously?
I've tried the empty array hack, which DOES stop useEffect from continuously firing, but it's not the desired behavior. If the user saves new data, for example, useEffect should fire again to get updated data - I'm not looking to emulate componentDidMount.
const Invoices = () => {
const [invoiceData, setInvoiceData] = useState([]);
useEffect(() => {
const updateInvoiceData = async () => {
const results = await api.invoice.findData();
setInvoiceData(results);
};
updateInvoiceData();
}, [invoiceData]);
return (
<Table entries={invoiceData} />
);
};
I expected useEffect to fire after the initial render, and again ONLY when invoiceData changes.
The way the useEffect dependency array works is by checking for strict (===) equivalency between all of the items in the array from the previous render and the new render. Therefore, putting an array into your useEffect dependency array is extremely hairy because array comparison with === checks equivalency by reference not by contents.
const foo = [1, 2, 3];
const bar = foo;
foo === bar; // true
const foo = [1, 2, 3];
const bar = [1, 2, 3];
foo === bar; // false
Inside of your effect function, when you do setInvoiceData(results) you are updating invoiceData to a new array. Even if all the items inside of that new array are exactly the same, the reference to the new invoiceData array has changed, causing the dependencies of the effect to differ, triggering the function again -- ad infinitum.
One simple solution is to simply remove invoiceData from the dependency array. In this way, the useEffect function basically acts similar to componentDidMount in that it will trigger once and only once when the component first renders.
useEffect(() => {
const updateInvoiceData = async () => {
const results = await api.invoice.findData();
setInvoiceData(results);
};
updateInvoiceData();
}, []);
This pattern is so common (and useful) that it is even mentioned in the official React Hooks API documentation:
If you want to run an effect and clean it up only once (on mount and
unmount), you can pass an empty array ([]) as a second argument. This
tells React that your effect doesn’t depend on any values from props
or state, so it never needs to re-run. This isn’t handled as a special
case — it follows directly from how the dependencies array always
works.
Credit to jered for the great "under the hood" explanation; I also found Milind's suggestion to separate out the update method from useEffect to be particularly fruitful.
My solution, truncated for brevity, is as follows -
const Invoices = () => {
const [invoiceData, setInvoiceData] = useState([]);
useEffect(() => {
updateInvoiceData();
}, []);
// Extracting this method made it accessible for context/prop-drilling
const updateInvoiceData = async () => {
const results = await api.invoice.findData();
setInvoiceData(results);
};
return (
<div>
<OtherComponentThatUpdatesData handleUpdateState={updateInvoiceData} />
<Table entries={invoiceData} />
</div>
);
};
What's happening, is that when you update the invoiceData, that technically changes the state of invoiceData, which you have watched by the useEffect hook, which causes the hook to run again, which updates invoiceData. If you want useEffect to run on mount, which I suspect, then pass an empty array to the second parameter of useEffect, which simulates componentDidMount in class components. Then, you'll be able to update the local UI state with your useState hook.
I totally agree with Jared's answer.
But for some scenarios where you really want to not have reference comparison, then useDeepCompareEffect from react-use library is really good
https://github.com/streamich/react-use/blob/HEAD/docs/useDeepCompareEffect.md