I am trying to route to '/' after the user successfully logs in.
Currently, in my Login.JS file, I have the handleSubmit function that gets the result from the form:
async function handleSubmit(e) {
e.preventDefault()
try {
setError("")
setLoading(true)
await login(emailRef.current.value, passwordRef.current.value)
history.push("/")
} catch(error) {
console.log(error)
setError("Failed to Log In")
}
setLoading(false)
}
Then, I have a AuthContext that passes the Login context
import React, { useContext, useEffect, useState } from 'react';
import { onAuthStateChanged, getAuth, signInWithEmailAndPassword} from 'firebase/auth';
import app from '../firebase'
const AuthContext = React.createContext()
export function useAuth() {
return useContext(AuthContext)
}
export function AuthProvider({ children }) {
const auth = getAuth()
const [currentUser, setCurrentUser] = useState()
const [loading, setLoading] = useState(true)
function login(email, password) {
return signInWithEmailAndPassword(auth, email, password)
}
useEffect(() => {
const unsubscribe = onAuthStateChanged(auth, (user) => {
setCurrentUser(user)
setLoading(false)
})
return unsubscribe;
}, [auth])
const value = {
currentUser,
login
}
return (
<AuthContext.Provider value={value}>
{!loading && children}
</AuthContext.Provider>
)
}
I can see that the user is able to LogIn, however, it doesn't render anything in the '/' page and shows this error message in the console:
Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.
There are two possible spots that might be causing this; i'm not sure which one it is.
First possibility: in the use effect, you set state twice back to back. React tries to batch multiple set states and do a single render, but since this is an asynchronous callback outside of react's control, it can't do so here. So you'll probably get one render for changing the user, then another render for changing loading. If that first render causes the component to unmount, it might result in the error when you set loading.
In react 18, this batching issue will be gone, but until then, you can make the two set states happen as a group like this:
import { unstable_batchedUpdates } from "react-dom";
// ...
useEffect(() => {
const unsubscribe = onAuthStateChanged(auth, (user) => {
unstable_batchedUpdates(() => {
setCurrentUser(user);
setLoading(false);
});
});
return unsubscribe;
}, [auth]);
Second possibility: it could be in handleSubmit. You set some state, kick off the login and await it, push to history, then set state again. If the component unmounts while waiting for the promise, or when pushing to history, you would get this issue. If this is the cause, then you can have a ref which gets updated when the component unmounts, and check that ref before doing your final set state:
const mounted = useRef(true);
useEffect(() => {
return () => {
mounted.current = false;
}
}, []);
async function handleSubmit(e) {
e.preventDefault();
try {
setError("");
setLoading(true);
await login(emailRef.current.value, passwordRef.current.value);
history.push("/");
} catch (error) {
console.log(error);
if (mounted.current) {
setError("Failed to Log In");
}
}
if (mounted.current) {
setLoading(false);
}
}
P.S, they will be removing this warning from react because of all the false positives it results in, your case being one of them. There's no actual memory leak in your code. You set state a single time after unmounting, which react harmlessly ignores, and then that's it You are correctly tearing down your onAuthStateChanged listener.
useEffect(() => {
const unsubscribe = onAuthStateChanged(auth, (user) => {
setCurrentUser(user)
setLoading(false)
})
return unsubscribe;
}, [auth])
You can not use a return statement rather than a cleanup function in useEffect hook.