In this code:
import React from 'react';
import './style.css';
let Child2 = () => {
React.useEffect(() => {
console.log('Child 2');
}, []);
return <div />;
};
let Child1 = ({ children }) => {
return <div>{children}</div>;
};
let FirstComponent = () => {
React.useEffect(() => {
console.log('FirstComponent');
}, []);
return <div />;
};
export default function App() {
React.useEffect(() => {
console.log('Main App');
}, []);
return (
<div>
<FirstComponent />
<Child1>
<Child2 />
</Child1>
</div>
);
}
The output is:
FirstComponent
Child 2
Main App
Question
Is there some reliable source (e.g. docs) so that we can say that always useEffect of
FirstComponent will precede useEffect of Child2?
Why is this relevant?
If we are sure that effect from FirstComponent always runs first, then it could be useful to perform some initialization work there (maybe perform some side effect), which we want to be available to all other useEffects in the app. We can't do this with normal parent/child effects, because you can see that parent effect ("Main App") runs after child effect ("Child 2").
Answering the question asked: As far as I'm aware, React doesn't guarantee the order of the calls to your component functions for the children, though it would be really surprising if they weren't in first-to-last order between siblings (so, reliably calling FirstComponent at least once before calling Child1 the first time, in that App). But although the calls to createElement will reliably be in that order, the calls to the component functions are done by React when and how it sees fit. It's hard to prove a negative, but I don't think it's documented that they'll be in any particular order.
But:
If we are sure that effect from FirstComponent always runs first, then it could be useful to perform some initialization work there, which we want to be available to all other useEffects in the app. We can't do this with normal parent/child effects, because you can see that parent effect ("Main App") runs after child effect ("Child 2".)
I wouldn't do that even if you find documentation saying the order is guaranteed. Crosstalk between sibling components is not a good idea. It means the components can't be used separately from each other, makes the components harder to test, and is unusual, making it surprising to people maintaining the codebase. You can do it anyway, of course, but as is often the case, lifting state up most likely applies ("state" in the general case, not just component state). Instead, do any one-time initialization you need to do in the parent (App) — not as an effect, but as component state in the parent, or instance state stored in a ref, etc., and pass it to the children via props, context, a Redux store, etc.
In the below, I'll pass things to the children via props, but that's just for the purposes of an example.
State
The usual place to store information used by child elements is in the parent's state. useState supports a callback function that will only be called during initialization. That's where to put this sort of thing unless you have a good reason not to. In the comments, you've suggested you have a good reason not to, but I'd be remiss if I didn't mention it in an answer meant for others in the future, not just for you now.
(This example and the second one below pass the information to the children via props, but again, it could be props, context, a Redux store, etc.)
Example:
const { useState, useEffect } = React;
let Child2 = () => {
return <div>Child 2</div>;
};
let Child1 = ({ value, children }) => {
return (
<div>
<div>value = {value}</div>
{children}
</div>
);
};
let FirstComponent = ({ value }) => {
return <div>value = {value}</div>;
};
function App() {
const [value] = useState(() => {
// Do one-time initialization here (pretend this is an
// expensive operation).
console.log("Doing initialization");
return Math.floor(Math.random() * 1000);
});
useEffect(() => {
return () => {
// This is called on unmount, clean-up here if necessary
console.log("Doing cleanup");
};
}, []);
return (
<div>
<FirstComponent value={value} />
<Child1 value={value}>
<Child2 />
</Child1>
</div>
);
}
const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(<App />);
<div id="root"></div>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/18.1.0/umd/react.development.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/18.1.0/umd/react-dom.development.js"></script>
Technically, I suppose you could use it for doing something that didn't result in any value at all, but that would be odd semantically and I don't think I'd recommend it.
Non-State
If it's information that can't be stored in state for some reason, you can use a ref, either to store it (although then you might prefer state) or to just store a flag saying "I've done my initialization." One-time initialization of refs is perfectly normal. And if the initialization requires cleanup, you can do that in a useEffect cleanup callback. Here's an example (this example does end up storing something other than a flag on the ref, but it could just be a flag):
const { useRef, useEffect } = React;
let Child2 = () => {
return <div>Child 2</div>;
};
let Child1 = ({ value, children }) => {
return (
<div>
<div>value = {value}</div>
{children}
</div>
);
};
let FirstComponent = ({ value }) => {
return <div>value = {value}</div>;
};
function App() {
// NOTE: This code isn't using state because the OP has a reason
// for not using state, which happens sometimes. But without
// such a reason, the normal thing to do here would be to use state,
// perhaps `useState` with a callback function to do it once
const instance = useRef(null);
if (!instance.current) {
// Do one-time initialization here, save the results
// in `instance.current`:
console.log("Doing initialization");
instance.current = {
value: Math.floor(Math.random() * 1000),
};
}
const { value } = instance.current;
useEffect(() => {
return () => {
// This is called on unmount, clean-up here if necessary
console.log("Doing cleanup");
};
}, []);
return (
<div>
<FirstComponent value={value} />
<Child1 value={value}>
<Child2 />
</Child1>
</div>
);
}
const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(<App />);
<div id="root"></div>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/18.1.0/umd/react.development.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/18.1.0/umd/react-dom.development.js"></script>
Your specific example use case
Re the specific use case you linked (note: the code from the question may not be correct; I'm not trying to correct it here, not least because I don't use axios):
I am using an axios interceptor to handle errors globally, but would like to set the state of my app from the interceptor.
axios.interceptors.response.use(
error => {
AppState.setError(error)
}
)
(And you've indicated that AppState, whatever it is, is only accessible within App.)
I'm not a fan of modifying the global axios instance, it's another crosstalky thing that affects all code using axios in the page/app, regardless of whether it's your code or code in a library that may use axios in a way where it's not appropriate for your app to show an error state that occurs.
I'd lean toward decoupling the interceptor from the App state update:
Have an axios wrapper module taht exports a custom axios instance
Put the interceptor on that instance
Provide a means of subscribing to error events from that module
Have App subscribe to the error event from that to set its state (and unsubscribe on unmount)
That sounds complicated, but it's only about 30 lines of code even if you don't have a prebuilt event emitter class:
import globalAxios from "axios";
const errorListeners = new Set();
export function errorSubscribe(fn) {
errorListeners.add(fn);
}
export function errorUnsubscribe(fn) {
errorListeners.delete(fn);
}
function useErrorListener(fn) {
const subscribed = useRef(false);
if (!subscribed.current) {
subscribed.current = true;
errorSubscribe(fn);
}
useEffect(() => {
return () => errorUnsubscribe(fn);
}, []);
}
export const axios = globalAxios.create({/*...config...*/});
instance.interceptors.response.use(() => {
(error) => {
for (const listener of errorListeners) {
try { listener(error); } catch {}
}
};
});
Then in App:
import { axios, useErrorListener } from "./axios-wrapper";
function App() {
useErrorListener((error) => AppState.setError(error));
// ...
}
In code that needs to use that instance of axios:
import { axios } from "./axios-wrapper";
// ...
That's a bit barebones (it assumes you'd never have dependencies on the error callback function, for instance), but you get the idea.
I second to #T.J. Crowder, you should not rely on execution order of components to implement any feature. For reasons:
What you want to achieve is anti-pattern, implicit dependency that surprises ppl. JUST DON'T DO IT.
It's not very reliable after all. The execution order is maintained, but continuity is not guaranteed.
I'll complement his answer with some details on execution order of React components.
So for a simple case of:
function A() {
return (<>
<B />
<C>
<D />
</C>
</>
);
}
The rule of thumb to determine component execution order, is to think in terms of JSX element creation call. In our case it'll be A(B(), C(D())), Same as JS function execution order, the execution (or "render") order of components would be B, D, C, A.
But this comes with caveats:
If any component bails out, e.g., D is a React.memo'ed "pure" component and its props doesn't change, then order would be B, C, A, order is maintained, but bailout component is skipped.
Not-so-everyday exception like SuspenseList (experimental)
<SuspenseList> coordinates the “reveal order” of the closest <Suspense> nodes below it.
which of cause affects execution order of its children by design.
In concurrent mode, because rendering can be interrupted at React's discretion, the continuity of execution order is in question. Sth like B, D, B, D, C, A could happen. (That said, useEffect seems unaffected AFAICT cus it's invoked in commit phase)
Related
I don't know why my React component is rendering twice. So I am pulling a phone number from params and saving it to state so I can search through Firestore. Everything seems to be working fine except it renders twice... The first one renders the phone number and zero points. The second time it renders all the data is displayed correctly. Can someone guide me to the solution.
class Update extends Component {
constructor(props) {
super(props);
const { match } = this.props;
this.state = {
phoneNumber: match.params.phoneNumber,
points: 0,
error: ''
}
}
getPoints = () => {
firebase.auth().onAuthStateChanged((user) => {
if(user) {
const docRef = database.collection('users').doc(user.uid).collection('customers').doc(this.state.phoneNumber);
docRef.get().then((doc) => {
if (doc.exists) {
const points = doc.data().points;
this.setState(() => ({ points }));
console.log(points);
} else {
// doc.data() will be undefined in this case
console.log("No such document!");
const error = 'This phone number is not registered yet...'
this.setState(() => ({ error }));
}
}).catch(function(error) {
console.log("Error getting document:", error);
});
} else {
history.push('/')
}
});
}
componentDidMount() {
if(this.state.phoneNumber) {
this.getPoints();
} else {
return null;
}
}
render() {
return (
<div>
<div>
<p>{this.state.phoneNumber} has {this.state.points} points...</p>
<p>Would you like to redeem or add points?</p>
</div>
<div>
<button>Redeem Points</button>
<button>Add Points</button>
</div>
</div>
);
}
}
export default Update;
You are running your app in strict mode. Go to index.js and comment strict mode tag. You will find a single render.
This happens is an intentional feature of the React.StrictMode. It only happens in development mode and should help to find accidental side effects in the render phase.
From the docs:
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:...
^ In this case the render function.
Official documentation of what might cause re-rendering when using React.StrictMode:
https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects
This is because of React Strict Mode code.
Remove -> React.StrictMode, from ReactDOM.render code.
Will render 2 times on every re-render:
ReactDOM.render(
<React.StrictMode>
<App />
</React.StrictMode>,
document.getElementById('root')
);
Will render 1 time:
ReactDOM.render(
<>
<App />
</>,
document.getElementById('root')
);
React is rendering the component before getPoints finishing the asynchronous operation.
So the first render shows the initial state for points which is 0, then componentDidMount is called and triggers the async operation.
When the async operation is done and the state been updated, another render is triggered with the new data.
If you want, you can show a loader or an indicator that the data is being fetched and is not ready yet to display with conditional rendering.
Just add another Boolean key like isFetching, set it to true when you call the server and set it to false when the data is received.
Your render can look something like this:
render() {
const { isFetching } = this.state;
return (
<div>
{isFetching ? (
<div>Loading...</div>
) : (
<div>
<p>
{this.state.phoneNumber} has {this.state.points} points...
</p>
<p>Would you like to redeem or add points?</p>
<div>
<button>Redeem Points</button>
<button>Add Points</button>
</div>
</div>
)}
</div>
);
}
React.StrictMode, makes it render twice, so that we do not put side effects in following locations
constructor
componentWillMount (or UNSAFE_componentWillMount)
componentWillReceiveProps (or UNSAFE_componentWillReceiveProps)
componentWillUpdate (or UNSAFE_componentWillUpdate)
getDerivedStateFromProps
shouldComponentUpdate
render
setState updater functions (the first argument)
All these methods are called more than once, so it is important to avoid having side-effects in them. If we ignore this principle it is likely to end up with inconsistent state issues and memory leaks.
React.StrictMode cannot spot side-effects at once, but it can help us find them by intentionally invoking twice some key functions.
These functions are:
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
This behaviour definitely has some performance impact, but we should not worry since it takes place only in development and not in production.
credit: https://mariosfakiolas.com/blog/my-react-components-render-twice-and-drive-me-crazy/
it is done intentionally by react to avoid this
remove
<React.StrictMode> </React.StrictMode>
from index.js
I worked around this by providing a custom hook. Put the hook below into your code, then:
// instead of this:
useEffect( ()=> {
console.log('my effect is running');
return () => console.log('my effect is destroying');
}, []);
// do this:
useEffectOnce( ()=> {
console.log('my effect is running');
return () => console.log('my effect is destroying');
});
Here is the code for the hook:
export const useEffectOnce = ( effect => {
const destroyFunc = useRef();
const calledOnce = useRef(false);
const renderAfterCalled = useRef(false);
if (calledOnce.current) {
renderAfterCalled.current = true;
}
useEffect( () => {
if (calledOnce.current) {
return;
}
calledOnce.current = true;
destroyFunc.current = effect();
return ()=> {
if (!renderAfterCalled.current) {
return;
}
if (destroyFunc.current) {
destroyFunc.current();
}
};
}, []);
};
See this blog for the explanation.
Well, I have created a workaround hook for this. Check this, if it helps:
import { useEffect } from "react";
const useDevEffect = (cb, deps) => {
let ran = false;
useEffect(() => {
if (ran) return;
cb();
return () => (ran = true);
}, deps);
};
const isDev = !process.env.NODE_ENV || process.env.NODE_ENV === "development";
export const useOnceEffect = isDev ? useDevEffect : useEffect;
CodeSandbox Demo: https://github.com/akulsr0/react-18-useeffect-twice-fix
React internally monitors & manages its render cycles using its virtual dom and its diffing algorithms, so you need not worry about the number of re-renders. Let the re-renders to be managed by react. Even though the render function is getting invoked, there are sub components which doesn't gets refreshed on ui, if there is no props or state change inside it. Every setstate function call will inform react to check the diffing algorithm, and invoke the render function.
So in your case, since you have a setstate defined inside the getPoints function, it tells react to rerun the diffing process through the render function.
I don't know why my React component is rendering twice. So I am pulling a phone number from params and saving it to state so I can search through Firestore. Everything seems to be working fine except it renders twice... The first one renders the phone number and zero points. The second time it renders all the data is displayed correctly. Can someone guide me to the solution.
class Update extends Component {
constructor(props) {
super(props);
const { match } = this.props;
this.state = {
phoneNumber: match.params.phoneNumber,
points: 0,
error: ''
}
}
getPoints = () => {
firebase.auth().onAuthStateChanged((user) => {
if(user) {
const docRef = database.collection('users').doc(user.uid).collection('customers').doc(this.state.phoneNumber);
docRef.get().then((doc) => {
if (doc.exists) {
const points = doc.data().points;
this.setState(() => ({ points }));
console.log(points);
} else {
// doc.data() will be undefined in this case
console.log("No such document!");
const error = 'This phone number is not registered yet...'
this.setState(() => ({ error }));
}
}).catch(function(error) {
console.log("Error getting document:", error);
});
} else {
history.push('/')
}
});
}
componentDidMount() {
if(this.state.phoneNumber) {
this.getPoints();
} else {
return null;
}
}
render() {
return (
<div>
<div>
<p>{this.state.phoneNumber} has {this.state.points} points...</p>
<p>Would you like to redeem or add points?</p>
</div>
<div>
<button>Redeem Points</button>
<button>Add Points</button>
</div>
</div>
);
}
}
export default Update;
You are running your app in strict mode. Go to index.js and comment strict mode tag. You will find a single render.
This happens is an intentional feature of the React.StrictMode. It only happens in development mode and should help to find accidental side effects in the render phase.
From the docs:
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:...
^ In this case the render function.
Official documentation of what might cause re-rendering when using React.StrictMode:
https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects
This is because of React Strict Mode code.
Remove -> React.StrictMode, from ReactDOM.render code.
Will render 2 times on every re-render:
ReactDOM.render(
<React.StrictMode>
<App />
</React.StrictMode>,
document.getElementById('root')
);
Will render 1 time:
ReactDOM.render(
<>
<App />
</>,
document.getElementById('root')
);
React is rendering the component before getPoints finishing the asynchronous operation.
So the first render shows the initial state for points which is 0, then componentDidMount is called and triggers the async operation.
When the async operation is done and the state been updated, another render is triggered with the new data.
If you want, you can show a loader or an indicator that the data is being fetched and is not ready yet to display with conditional rendering.
Just add another Boolean key like isFetching, set it to true when you call the server and set it to false when the data is received.
Your render can look something like this:
render() {
const { isFetching } = this.state;
return (
<div>
{isFetching ? (
<div>Loading...</div>
) : (
<div>
<p>
{this.state.phoneNumber} has {this.state.points} points...
</p>
<p>Would you like to redeem or add points?</p>
<div>
<button>Redeem Points</button>
<button>Add Points</button>
</div>
</div>
)}
</div>
);
}
React.StrictMode, makes it render twice, so that we do not put side effects in following locations
constructor
componentWillMount (or UNSAFE_componentWillMount)
componentWillReceiveProps (or UNSAFE_componentWillReceiveProps)
componentWillUpdate (or UNSAFE_componentWillUpdate)
getDerivedStateFromProps
shouldComponentUpdate
render
setState updater functions (the first argument)
All these methods are called more than once, so it is important to avoid having side-effects in them. If we ignore this principle it is likely to end up with inconsistent state issues and memory leaks.
React.StrictMode cannot spot side-effects at once, but it can help us find them by intentionally invoking twice some key functions.
These functions are:
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
This behaviour definitely has some performance impact, but we should not worry since it takes place only in development and not in production.
credit: https://mariosfakiolas.com/blog/my-react-components-render-twice-and-drive-me-crazy/
it is done intentionally by react to avoid this
remove
<React.StrictMode> </React.StrictMode>
from index.js
I worked around this by providing a custom hook. Put the hook below into your code, then:
// instead of this:
useEffect( ()=> {
console.log('my effect is running');
return () => console.log('my effect is destroying');
}, []);
// do this:
useEffectOnce( ()=> {
console.log('my effect is running');
return () => console.log('my effect is destroying');
});
Here is the code for the hook:
export const useEffectOnce = ( effect => {
const destroyFunc = useRef();
const calledOnce = useRef(false);
const renderAfterCalled = useRef(false);
if (calledOnce.current) {
renderAfterCalled.current = true;
}
useEffect( () => {
if (calledOnce.current) {
return;
}
calledOnce.current = true;
destroyFunc.current = effect();
return ()=> {
if (!renderAfterCalled.current) {
return;
}
if (destroyFunc.current) {
destroyFunc.current();
}
};
}, []);
};
See this blog for the explanation.
Well, I have created a workaround hook for this. Check this, if it helps:
import { useEffect } from "react";
const useDevEffect = (cb, deps) => {
let ran = false;
useEffect(() => {
if (ran) return;
cb();
return () => (ran = true);
}, deps);
};
const isDev = !process.env.NODE_ENV || process.env.NODE_ENV === "development";
export const useOnceEffect = isDev ? useDevEffect : useEffect;
CodeSandbox Demo: https://github.com/akulsr0/react-18-useeffect-twice-fix
React internally monitors & manages its render cycles using its virtual dom and its diffing algorithms, so you need not worry about the number of re-renders. Let the re-renders to be managed by react. Even though the render function is getting invoked, there are sub components which doesn't gets refreshed on ui, if there is no props or state change inside it. Every setstate function call will inform react to check the diffing algorithm, and invoke the render function.
So in your case, since you have a setstate defined inside the getPoints function, it tells react to rerun the diffing process through the render function.
I don't know why my React component is rendering twice. So I am pulling a phone number from params and saving it to state so I can search through Firestore. Everything seems to be working fine except it renders twice... The first one renders the phone number and zero points. The second time it renders all the data is displayed correctly. Can someone guide me to the solution.
class Update extends Component {
constructor(props) {
super(props);
const { match } = this.props;
this.state = {
phoneNumber: match.params.phoneNumber,
points: 0,
error: ''
}
}
getPoints = () => {
firebase.auth().onAuthStateChanged((user) => {
if(user) {
const docRef = database.collection('users').doc(user.uid).collection('customers').doc(this.state.phoneNumber);
docRef.get().then((doc) => {
if (doc.exists) {
const points = doc.data().points;
this.setState(() => ({ points }));
console.log(points);
} else {
// doc.data() will be undefined in this case
console.log("No such document!");
const error = 'This phone number is not registered yet...'
this.setState(() => ({ error }));
}
}).catch(function(error) {
console.log("Error getting document:", error);
});
} else {
history.push('/')
}
});
}
componentDidMount() {
if(this.state.phoneNumber) {
this.getPoints();
} else {
return null;
}
}
render() {
return (
<div>
<div>
<p>{this.state.phoneNumber} has {this.state.points} points...</p>
<p>Would you like to redeem or add points?</p>
</div>
<div>
<button>Redeem Points</button>
<button>Add Points</button>
</div>
</div>
);
}
}
export default Update;
You are running your app in strict mode. Go to index.js and comment strict mode tag. You will find a single render.
This happens is an intentional feature of the React.StrictMode. It only happens in development mode and should help to find accidental side effects in the render phase.
From the docs:
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:...
^ In this case the render function.
Official documentation of what might cause re-rendering when using React.StrictMode:
https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects
This is because of React Strict Mode code.
Remove -> React.StrictMode, from ReactDOM.render code.
Will render 2 times on every re-render:
ReactDOM.render(
<React.StrictMode>
<App />
</React.StrictMode>,
document.getElementById('root')
);
Will render 1 time:
ReactDOM.render(
<>
<App />
</>,
document.getElementById('root')
);
React is rendering the component before getPoints finishing the asynchronous operation.
So the first render shows the initial state for points which is 0, then componentDidMount is called and triggers the async operation.
When the async operation is done and the state been updated, another render is triggered with the new data.
If you want, you can show a loader or an indicator that the data is being fetched and is not ready yet to display with conditional rendering.
Just add another Boolean key like isFetching, set it to true when you call the server and set it to false when the data is received.
Your render can look something like this:
render() {
const { isFetching } = this.state;
return (
<div>
{isFetching ? (
<div>Loading...</div>
) : (
<div>
<p>
{this.state.phoneNumber} has {this.state.points} points...
</p>
<p>Would you like to redeem or add points?</p>
<div>
<button>Redeem Points</button>
<button>Add Points</button>
</div>
</div>
)}
</div>
);
}
React.StrictMode, makes it render twice, so that we do not put side effects in following locations
constructor
componentWillMount (or UNSAFE_componentWillMount)
componentWillReceiveProps (or UNSAFE_componentWillReceiveProps)
componentWillUpdate (or UNSAFE_componentWillUpdate)
getDerivedStateFromProps
shouldComponentUpdate
render
setState updater functions (the first argument)
All these methods are called more than once, so it is important to avoid having side-effects in them. If we ignore this principle it is likely to end up with inconsistent state issues and memory leaks.
React.StrictMode cannot spot side-effects at once, but it can help us find them by intentionally invoking twice some key functions.
These functions are:
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
This behaviour definitely has some performance impact, but we should not worry since it takes place only in development and not in production.
credit: https://mariosfakiolas.com/blog/my-react-components-render-twice-and-drive-me-crazy/
it is done intentionally by react to avoid this
remove
<React.StrictMode> </React.StrictMode>
from index.js
I worked around this by providing a custom hook. Put the hook below into your code, then:
// instead of this:
useEffect( ()=> {
console.log('my effect is running');
return () => console.log('my effect is destroying');
}, []);
// do this:
useEffectOnce( ()=> {
console.log('my effect is running');
return () => console.log('my effect is destroying');
});
Here is the code for the hook:
export const useEffectOnce = ( effect => {
const destroyFunc = useRef();
const calledOnce = useRef(false);
const renderAfterCalled = useRef(false);
if (calledOnce.current) {
renderAfterCalled.current = true;
}
useEffect( () => {
if (calledOnce.current) {
return;
}
calledOnce.current = true;
destroyFunc.current = effect();
return ()=> {
if (!renderAfterCalled.current) {
return;
}
if (destroyFunc.current) {
destroyFunc.current();
}
};
}, []);
};
See this blog for the explanation.
Well, I have created a workaround hook for this. Check this, if it helps:
import { useEffect } from "react";
const useDevEffect = (cb, deps) => {
let ran = false;
useEffect(() => {
if (ran) return;
cb();
return () => (ran = true);
}, deps);
};
const isDev = !process.env.NODE_ENV || process.env.NODE_ENV === "development";
export const useOnceEffect = isDev ? useDevEffect : useEffect;
CodeSandbox Demo: https://github.com/akulsr0/react-18-useeffect-twice-fix
React internally monitors & manages its render cycles using its virtual dom and its diffing algorithms, so you need not worry about the number of re-renders. Let the re-renders to be managed by react. Even though the render function is getting invoked, there are sub components which doesn't gets refreshed on ui, if there is no props or state change inside it. Every setstate function call will inform react to check the diffing algorithm, and invoke the render function.
So in your case, since you have a setstate defined inside the getPoints function, it tells react to rerun the diffing process through the render function.
I know this question is already asked here: How to set initial state for useState Hook in jest and enzyme?
const [state, setState] = useState([]);
And I totally agree with Jimmy's Answer to mock the useState function from test file but I have some extended version of this question, "What if I have multiple useState statements into the hooks, How can I test them and assign the respective custom values to them?"
I have some JSX rendering with the condition of hook's state values and depending on the values of that state the JSX is rendering.
How Can I test those JSX by getting them into the wrapper of my test case code?
Upon the answer you linked, you can return different values for each call of a mock function:
let myMock = jest.fn();
myMock
.mockReturnValueOnce(10)
.mockReturnValueOnce('x')
.mockReturnValue(true);
In my opinion this is still brittle. You may modify the component and add another state later, and you would get confusing results.
Another way to test a React component is to test it like a user would by clicking things and setting values on inputs. This would fire the event handlers of the component, and React would update the state just as in real configuration. You may not be able to do shallow rendering though, or you may need to mock the child components.
If you prefer shallow rendering, maybe read initial state values from props like this:
function FooComponent({initialStateValue}) {
const [state, setState] = useState(initialStateValue ?? []);
}
If you don't really need to test state but the effects state has on children, you should (as some comments mention) just then test the side effect and treat the state as an opaque implementation detail. This will work if your are not using shallow rendering or not doing some kind of async initialization like fetching data in an effect or something otherwise it could require more work.
If you cant do the above, you might consider removing state completely out of the component and make it completely functional. That way any state you need, you can just inject it into the component. You could wrap all of the hooks into a 'controller' type hook that encapsulates the behavior of a component or domain. Here is an example of how you might do that with a <Todos />. This code is 0% tested, its just written to show a concept.
const useTodos = (state = {}) => {
const [todos, setTodos] = useState(state.todos);
const id = useRef(Date.now());
const addTodo = useCallback((task) => {
setTodos((current) => [...current, { id: id.current++, completed: false, task }]);
}, []);
const removeTodo = useCallback((id) => {
setTodos((current) => current.filter((t) => t.id !== id));
}, []);
const completeTodo = useCallback((id) => {
setTodos((current) => current.map((t) => {
let next = t;
if (t.id === id) {
next = { ...t, completed: true };
}
return next;
}))
}, []);
return { todos, addTodo, removeTodo, completeTodo };
};
const Todos = (props) => {
const { todos, onAdd, onRemove, onComplete } = props;
const onSubmit = (e) => {
e.preventDefault();
onAdd({ task: e.currentTarget.elements['todo'].value });
}
return (
<div classname="todos">
<ul className="todos-list">
{todos.map((todo) => (
<Todo key={todo.id} onRemove={onRemove} onComplete={onComplete} />
)}
</ul>
<form className="todos-form" onSubmit={onSubmit}>
<input name="todo" />
<button>Add</button>
</form>
</div>
);
};
So now the parent component injects <Todos /> with todos and callbacks. This is useful for testing, SSR, ect. Your component can just take a list of todos and some handlers, and more importantly you can trivially test both. For <Todos /> you can pass mocks and known state and for useTodos you would just call the methods and make sure the state reflects what is expected.
You might be thinking This moves the problem up a level and it does, but you can now test the component/logic and increase test coverage. The glue layer would require minimal if any testing around this component, unless you really wanted to make sure props are passed into the component.
The Rules of Hooks require that the same hooks and in the same order are called on every render. And there is an explanation about what goes wrong if you break this rule. For example this code:
function App() {
console.log('render');
const [flag, setFlag] = useState(true);
const [first] = useState('first');
console.log('first is', first);
if (flag) {
const [second] = useState('second');
console.log('second is', second);
}
const [third] = useState('third');
console.log('third is', third);
useEffect(() => setFlag(false), []);
return null;
}
Outputs to console
render
first is first
second is second
third is third
render
first is first
third is second
And causes a warning or an error.
But what about conditions that do not change during the element lifecycle?
const DEBUG = true;
function TestConst() {
if (DEBUG) {
useEffect(() => console.log('rendered'));
}
return <span>test</span>;
}
This code doesn't really break the rules and seems to work fine. But it still triggers the eslint warning.
Moreover it seems to be possible to write similar code based on props:
function TestState({id, debug}) {
const [isDebug] = useState(debug);
if (isDebug) {
useEffect(() => console.log('rendered', id));
}
return <span>{id}</span>;
}
function App() {
const [counter, setCounter] = useState(0);
useEffect(() => setCounter(1), []);
return (
<div>
<TestState id="1" debug={false}/>
<TestState id="2" debug={true}/>
</div>
);
}
This code works as intended.
So is it safe to call hooks inside a condition when I am sure that it is not going to change? Is it possible to modify the eslint rule to recognise such situations?
The question is more about the real requirement and not the way to implement similar behaviour. As far as I understand it is important to
ensure that Hooks are called in the same order each time a component
renders. That’s what allows React to correctly preserve the state of
Hooks between multiple useState and useEffect calls
And there is a place for exceptions to this rule: "Don’t call Hooks inside loops, conditions, or nested functions".
Although you can write hooks conditionally like you mentioned above and it may work currently, it can lead to unexpected behavior in the future. For instance in the current case you aren't modifying the isDebug state.
Demo
const {useState, useEffect} = React;
function TestState({id, debug}) {
const [isDebug, setDebug] = useState(debug);
if (isDebug) {
useEffect(() => console.log('rendered', id));
}
const toggleButton = () => {
setDebug(prev => !prev);
}
return (
<div>
<span>{id}</span>
<button type="button" onClick={toggleButton}>Toggle debug</button>
</div>
);
}
function App() {
const [counter, setCounter] = useState(0);
useEffect(() => setCounter(1), []);
return (
<div>
<TestState id="1" debug={false}/>
<TestState id="2" debug={true}/>
</div>
);
}
ReactDOM.render(<App />, document.getElementById('app'));
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/16.8.3/umd/react.production.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/16.8.3/umd/react-dom.production.min.js"></script>
<div id="app"/>
As a rule of thumb you shouldn't violate the rules since it may cause problems in future. You could handle the above scenarios in the following way without violating the rules
const {useState, useEffect} = React;
function TestState({id, debug}) {
const [isDebug, setDebug] = useState(debug);
useEffect(() => {
if(isDebug) {
console.log('rendered', id)
}
}, [isDebug]);
const toggleButton = () => {
setDebug(prev => !prev);
}
return (
<div>
<span>{id}</span>
<button type="button" onClick={toggleButton}>Toggle debug</button>
</div>
);
}
function App() {
const [counter, setCounter] = useState(0);
useEffect(() => setCounter(1), []);
return (
<div>
<TestState id="1" debug={false}/>
<TestState id="2" debug={true}/>
</div>
);
}
ReactDOM.render(<App />, document.getElementById('app'));
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/16.8.3/umd/react.production.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/16.8.3/umd/react-dom.production.min.js"></script>
<div id="app"/>
For your use-case I don't see the problem, I don't see how this can break in the future, and you are right that it works as intended.
However, I think the warning is actually legit and should be there at all times, because this can be a potential bug in your code (not in this particular one)
So what I'd do in your case, is to disable react-hooks/rules-of-hooks rule for that line.
ref: https://reactjs.org/docs/hooks-rules.html
This hook rule address common cases when problems that may occur with conditional hook calls:
Don’t call Hooks inside loops, conditions, or nested functions. Instead, always use Hooks at the top level of your React function. By following this rule, you ensure that Hooks are called in the same order each time a component renders.
If a developer isn't fully aware of consequences, this rule is a safe choice and can be used as a rule of thumb.
But the actual rule here is:
ensure that Hooks are called in the same order each time a component renders
It's perfectly fine to use loops, conditions and nested functions, as long as it's guaranteed that hooks are called in the same quantity and order within the same component instance.
Even process.env.NODE_ENV === 'development' condition can change during component lifespan if process.env.NODE_ENV property is reassigned at runtime.
If a condition is constant, it can be defined outside a component to guarantee that:
const isDebug = process.env.NODE_ENV === 'development';
function TestConst() {
if (isDebug) {
useEffect(...);
}
...
}
In case a condition derives from dynamic value (notably initial prop value), it can be memoized:
function TestConst({ debug }) {
const isDebug = useMemo(() => debug, []);
if (isDebug) {
useEffect(...);
}
...
}
Or, since useMemo isn't guaranteed to preserve values in future React releases, useState (as the question shows) or useRef can be used; the latter has no extra overhead and a suitable semantics:
function TestConst({ debug }) {
const isDebug = useRef(debug).current;
if (isDebug) {
useEffect(...);
}
...
}
In case there's react-hooks/rules-of-hooks ESLint rule, it can be disabled per line basis.
Please don't use this pattern. It may work in your example but it is not nice (or idiomatic).
The standard pattern (for good reason) is that initial state is declared in the constructor and then updated in response to some condition in the body (setState). React Hooks mirror this functionality in stateless components - so it should work the same.
Secondly, I cannot see how it is useful to dynamically add this piece of state and potentially cause rendering problems later down the line. In your example, a simple const would work just as well - there is no reason to use dynamic state.
Consider this:
return (<React.Fragment>{second}</React.Fragment>)
This breaks with a Reference error whenever you don't have second defined.