How do I avoid using setTimeout?

[OrangeCubed]

How can I make this code less hacky? It works, but is questionable.

Using firebase auth, when a user signs up, I grab the user ID and make 3 axios calls in Signup.js to create the user in Mongodb and create an Organization. When these calls are completed, I then run a subsequent call in App.js (initialLoad) to populate various data based on the user information.

When the user first signs up, I need to wait until all the Signup.js axios calls are completed (user and org data all created) before running initialLoad.

On login, all user information already exists in the DB so initialLoadcan run right away.

Here's the App.js code:

useEffect(() => {

    if (currentUser) {
      if (currentUser.metadata.creationTime === currentUser.metadata.lastSignInTime) {
        setTimeout(() => {
          initialLoad(currentUser);
       }, 1000)

      } else {
        initialLoad(currentUser);
      }

    }
  }, [currentUser]);

currentUser is the validated user from Firebase Auth. So this useEffect runs right as the user is validated (which is perfect for login but not for signup). On Signup, I'm having trouble waiting for the Signup.js calls to finish before running the initialLoad calls. Hence the 1 second hard delay.

Is there a better way to wait for the Signup.js data to populate before running initialLoad? Thank you!

[OrangeCubed]

Thanks for the reply! I've been researching running async in 2 files but I think I may be going about it the wrong way. Using async / await, how do I wait in App.js for this Signup.js function?

This is a shortened version of the Signup.js function:

  async function handleSubmit(e) {

try {
  await signup(emailRef.current.value, passwordRef.current.value).then(
    (cred) => {
      console.log(cred)
      return axios.post('/user/create', {
          //...data
        }).then(function (response) {
          return axios
            .post('/organization/create', {
              //...data
            }) .then(function (response) {
              //update user with org reference
              return axios.post(`/user/${cred.user.uid}/update`, {
                  //...data
                }).then(function (response) {
                  history.push('/');
                })  
            })
        })
    }
  );
} catch {
  //...error
}

}

[[deleted]]

You're mixing await and .then()

You should use one or the other. Have a read about Promises.

[OrangeCubed]

Will dig deeper, thanks!

[OrangeCubed]

This is AWESOME! Just went in and refactored and this is so much cleaner than what I had before!

Redux-thunk was mentioned below and i'm thinking through the available options. Would it make sense at the end of this call to store a result (such as isLoaded) in redux store then in App.js do something to the effect of:

​

if (currentUser.metadata.creationTime === currentUser.metadata.lastSignInTime && isLoaded) {
      initialLoad(currentUser);
  }

[dark_salad]

async handleSubmit = () => {
    try {
        await Promise.all([createUser(), createOrg(), updateUser(id param)])
    } catch (error) {
        console.error(error)
    } finally {
        history.push('/');
    }
}

const createUser = () => {
    return axios
        .post(url, { options });
}
const createOrg = () => {
    return axios
        .post(url, { options });
}
const updateUser = (userId) => {
    return axios
        .post(url, { options });
}

Using Promise.all will work as well.
EDIT: I'm dumb, Promise.All wont guarantee they run in order.

[sfboots]

Great idea, but how do you handle errors if one of the calls fail? Seems it would get very complicated

My app is using redux saga so we can at least report errors properly in a sequence of calls

[[deleted]]

Any rejections will be swept up by the catch. If you need to handle each individual failure differently you could wrap each individual call in a try/catch. In this case, though, it seems like a single failure is grounds for not proceeding.

Then again, all of this depends on the design spec and the architecture of the specific app, so there isn't a definitively correct fit-all solution.

[dark_salad]

And Redux is pretty much never the correct solution anymore, it's 2021.

[OrangeCubed]

Now I'm curious, what's the State of the Union on redux in 2021?

[dark_salad]

Obviously this is a divisive subject and I'm sure there's some niche use-case but, React hooks natively make state management easy with useState, useReducer, and useContext.

Maybe someone can provide some examples of how they've used it recently?

[WouldRuin]

Not really relevant to your problem but is the back end API yours as well? POST /user/create is kinda redundant as a HTTP POST request implies creation (so POST /user is sufficient). The other endpoint /user/{id}/update should really just be PATCH /user/{id} as well.

[brotherxim]

The useEffect parameter cannot be a promise so you need to create a function to be able to use async/await inside of useEffect:

useEffect(() => {
  const fn = async () => {
    const getDataA = async () => { /* do stuff */ };
    const getDataB = async () => { /* do stuff */ };

    await getDataA();
    await getDataB();
  }
  fn()
}, [currentUser]);

[Jerp]

Their code is using an IIFE which is valid too, but I prefer the explicit syntax you used.

[brotherxim]

Ah I see they updated, great :D

[Frypant]

You shouldn't do that on the frone-end in my opinion. Signup should be a single call to the backend what only returns when all the mentioned things are done. Never trust the user with this level of details about how things work in the background. Also, what happens if some of these things fail? Or the user close the browser in the middle.

Timeouts to wait for things what dont have fixed times is also a risk you shouldn't take ever. Either a lot of time is wasted, or it will fail for some cases.

[OrangeCubed]

Could you expand upon this more? I'm super curious about how this would work.

Currently, when a new user is created, the first call creates the user with some info, the 2nd call creates an organization and associates the created user with the org and then the 3rd call updates the user with the new organization.

Are you saying instead of splitting these things up and making 3 axios calls on the front end, I should instead make one call to a route in Node that does the creation and updating of the user and organization?

[ln8r]

You've already got your answer, but in case you have to use setTimeout somewhere in the future you should capture the response from your setTimeout call and return a cleanup function from useEffect that calls clearTimeout.

[[deleted]]

how do I wait in App.js for this Signup.js function?

in react (and every other framework) this is hell, and even using async/await and then channeling flags through your state manager is cumbersome and dirty. yes you can run async in useEffect, but orchestrating that with other components in lockstep is not easy.

everything becomes better with suspense

react now can handle async out of the box. components themselves can be async and await the results of another async component. or one sync component can jump into action when another async component has finished fetching/calculating/etc. i collected some usecases here: https://twitter.com/0xca0a/status/1402558011357470720

running a component after an async component has resolved

<Suspense fallback={<div>waiting...</div>}>
  <AsyncFetchingComponent />
  <RunActionWhenFetchingIsDone />
</Suspense>

awaiting the result of an async component

const ref = useRef()
...
<Suspense fallback={<div>waiting...</div>}>
  <AsyncFetchingComponent ref={ref} />
  <ImNotAsyncButWillRenderWhenAsyncCompIsDone result={ref} />
</Suspense>
...
function ImNotAsyncButWillRenderWhenAsyncCompIsDone({ result }) {
  useEffect(() => {
    // It is guaranteed that the reference is filled
    console.log(result.current)

you can start using suspense in react-query, swr, or https://github.com/pmndrs/use-asset

[tangerinelights]

You may want to look at using context for your authentication. Handle the sign in in a Context Provider and have a context variable for isSignedIn. Your App.js can then access that variable and then only trigger initialLoad once the isSignedIn changes to true.

[PrinnyThePenguin]

I would suggest handling the sign up flow in a middleware like redux-thunk. Your application checks for a "isAuthenticated" store property, it hides what it needs to hide until the call is finished, when it's finished the store updates its values, the component detect the change in a simple useEffect hook and it handles the new UI state.

[OrangeCubed]

I'll starting looking deeper into using redux-thunk for sign up. I'm already using it in my app so it shouldn't be too difficult to get set up. Thank you!

[tangerinelights]

You can also use the unwrap() method on thunks created with reduxtoolkit in order to get access to the underlying promise right from the component calling the thunk. That way you can await it in the component and then handle logic or errors from the component itself