We Keep Coding

What is the proper way to create an event handler inside a React function component? [duplicate]

This question already has answers here:
Function inside functional component in React hooks - Performance
(8 answers)
Closed 6 months ago.
I'm currently learning react.js and I just want to ask a question on how to properly create an event handler function inside a function component.
Pardon me since most examples in the official documentation are using class for this types of components.
I have an example code below that seems to work fine, but I'm not sure if this is the correct way/best practice when creating an event handler inside a function component, since every time the state changes I assume that the handleClick function is also recreated isn't it? This affects the performance every time we re-render right?
Say for example when I add more elements inside the return statement that can also trigger an event, and each event has a corresponding event handler that is also declared in that same function component, that might be an overhead for those extreme cases 'isn't that correct?
As far as I know this is not a problem on class components because they have a separate render() method so the event handler functions are not recreated, how do we do this in function components?
function Toggle (props) {
const [isToggleOn, setToggle] = React.useState(false)
function handleClick (e) {
setToggle(() => !isToggleOn)
}
return (
<button onClick={handleClick}>
{isToggleOn ? 'ON' : 'OFF'}
</button>
)
}

If you don't want the handleClick function to be recreated on each render, you should use useCallback hook.
const handleClick = useCallback(() => {
setToggle((previousState) => !previousState)
}, [])
This way, handleClick is created only at the initial render because the useCallback's dependency array is empty.
You might also notice that I removed the usage of isToggleOn and instead use the previous state in the setToggle so your function don't need to depend on isToggleOn.

Weird React render issues [duplicate]

This question already has answers here:
React useState cause double rendering
(3 answers)
What is StrictMode in React?
(4 answers)
Closed 1 year ago.
So after working with react in the past year, i managed to understand its powers and caveats, and how to avoid unnecessary renders.
Yesterday i was playing with some code and came across an issue i didnt see before, and got a little confuse.
import React, { useCallback, useState } from "react";
let renders = 0;
const Counter = () => {
const [count, setCount] = useState(0);
const increment = useCallback(() => {
setCount((c) => c + 1);
}, []);
renders = renders + 1;
console.log("Counter Render");
return (
<div>
<button onClick={increment}>increment</button>
<h2>renders: {renders}</h2>
<h4>Count: {count}</h4>
</div>
);
};
export default React.memo(Counter);
in the above code i added a simple counter, on every click i am setting a new state, which cause a re-render, showing "Count: 1" on the screen and one "Counter Render" log in dev tools - just like i expected.
The weird part comes from the renders variable, which i initiate with the number 0 ( outside the component, offcourse ) and increment on every render of the component.
i would have expect the value here will also be 1 but that is not the case, every time i click the button the value of "renders" grows by 2, even though the "Counter Render" log show once each time.
Here is a the Sandbox example
can anyone explain what am i missing here ?

You're running in React's Strict Mode (since your app is wrapped in <StrictMode>).
Strict Mode may render components multiple times to make sure you're not doing naughty things such as relying on render counts – which you now are. ;-)

Why does calling useState's setter with the same value subsequently trigger a component update even if the old state equals the new state?

This problem occurs only if the state value was actually changed due to the previous update.
In the following example, when the button is clicked for the first time, "setState" is called with a new value (of 12), and a component update occurs, which is understandable.
When I click the same button for the second time, setting the state to the same value of 12 it causes the component to re-run (re-render), and why exactly that happens is my main question.
Any subsequent setStates to the same value of 12 will not trigger a component update, which is again, understandable. 12 === 12 so no update is needed.
So, why is the update happening on the second click of the button?
export default function App() {
const [state, setState] = useState(0);
console.log("Component updated");
return (
<div className="App">
<h1>Hello CodeSandbox {state}</h1>
<button onClick={() => setState(12)}>Button</button>
</div>
);
}
Codesandbox example

The main question is, why logging in function component body causes 3 logs of "Component updated"?
The answer is hiding somewhere in React docs:
if you update a State Hook to the same value as the current state, React will bail out without rendering the children or firing effects.
Nothing new, but then:
Note that React may still need to render that specific component again before bailing out. That shouldn’t be a concern because React won’t unnecessarily go “deeper” into the tree.
But notice useEffect API definition:
will run after the render is committed to the screen.
If you log the change in useEffect you notice only two "B" logs as expected, which is exactly the example for bail out behavior mentioned:
const App = () => {
const [state, setState] = React.useState(0);
useEffect(() => {
console.log("B");
});
console.log("A");
return (
<>
<h1>{state}</h1>
<button onClick={() => setState(42)}>Click</button>
</>
);
};
There will be an additional "Bail out" call for App component (extra "A" log), but React won't go "deeper" and won't change the existing JSX or state (no additional "B" will be logged).

Adding to the generally correct accepted answer, there is what i've found diving deeper in that problem:
There is actually more complex mechanics in that.
Actually, any setState call is applying reducer function under the hood, and that reducer function runs on next useState call, not before component function execution.
So normally there is no way of knowing if new state will be the same or not without executing executing that reducer (on useState call).
On the other hand however, when such reducer was once executed and state was not changed, component's return is ignored (render skipped) and next call of that reducer will be executed before component's function and NOT when useState called. That is also true for the very first setState of the component's life.
I've made a demo of that in codesandbox

Component rendering multiple times without any reason

I was facing multiple re-renders and thus to find the issue I commented every line of code and at last found the constant definition causing re-render:
const MyComponent = () => {
console.log('render') // logs 4 times
const myRef = useRef(null)
return <h1>hello</h1>
}
const MyComponent = () => {
console.log('render') // logs 2 times
return <h1>hello</h1>
}
I know strict mode renders the component 2 times. But, why just defining myRef constant causing re-render further 2 times?
I just tried React.memo as comment, but it still renders 4 times:
export default React.memo(MyComponent)
Okay, I just tested using the same code in App.js and it only logged 2 times. So, it seems to be parent component issue. But my question is why in the child component without having anything causing renders additional 2 times just defining the variable?

As you and React docs said:
Strict mode can’t automatically detect side effects for you, but it
can help you spot them by making them a little more deterministic.
This is done by intentionally double-invoking the following functions:
Class component constructor, render, and shouldComponentUpdate methods
Class component static getDerivedStateFromProps method
Function component bodies
State updater functions (the first argument to setState)
Functions passed to useState, useMemo, or useReducer
Source: https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects
It does not include useRef but it actually should be on this list because it uses same underlying mechanism as useState
React.memo won't help here because what causes re-render is React.StrictMode special mechanism to check side effects and other stuff, so it ignores memo and similar techniques.
What's interesting here that if you add useRef in Parent component it will invoke function body 2 times, but its children (if they don't use useRef) are gonna be invoked only once.
All this stuff only works for development mode, so in production there won't be any intentional double invocations and other things but they can still happen unintentionally.

Problems setting useState inside onClick handler [duplicate]

This question already has answers here:
Why does calling react setState method not mutate the state immediately?
(9 answers)
How does JavaScript mechanism behind react hooks work?
(2 answers)
Closed 3 years ago.
I am using useState hook inside onClick handler to change and track the focus state. I set it to false initially and then change it to true and false several times in the handler. After each change, I do console.log(focus) and I expect it to be respective to the changes made.
function App() {
const [focus, setFocus] = useState(false);
return (
<div
className="App"
onClick={() => {
console.log(focus);
setFocus(true);
console.log(focus);
setFocus(false);
console.log(focus);
}}
>
<h1>App</h1>
</div>
);
}
In my case, in this code snippet, I expect to see in console false, true and then false again, but I see all of them false.
Why does it happen? I feel I am missing something quite fundamental here.

When you set the state, the component will be re-rendered. State changes are not synchronous in nature. Try adding a console.log below your useState line and you'll see that it gets called every time you set the focus because the entire component is re-rendered.