Return a promise from submit

[jabrks]

I would like to be able to submit an action from inside an event handler and call a function after the submit has finished. At the moment, my implementation looks something like this

import { useEffect, useState } from 'react';
import { useActionData, useSubmit } from '@remix-run/react';

function Component() {
  const submit = useSubmit();
  const actionData = useActionData();
  const [completeFn, setCompleteFn] = useState();

  useEffect(() => {
    customLibrary.on('customEvent', (complete) => {
      setCompleteFn(complete);
      const formData = new FormData();
      submit(formData, { method: 'post' });
    });
  }, [submit]);

  useEffect(() => {
    if (actionData && completeFn) {
      completeFn(actionData);
    }
  }, [actionData, completeFn]);

  // ...
}

completeFn could alternatively be stored in a ref instead, but the rest of the code remains largely the same.

If submit returned a promise that resolved once the request had completed, it could look something like this instead

import { useEffect } from 'react';
import { useSubmit } from '@remix-run/react';

function Component() {
  const submit = useSubmit();

  useEffect(() => {
    customLibrary.on('customEvent', (complete) => {
      const formData = new FormData();
      submit(formData, { method: 'post' }).then((actionData) => complete(actionData));
    });
  }, [submit]);

  // ...
}

I have considered some alternatives, such as using fetch to call the action directly, but decided against it as it would essentially mean opting out of Remix's transition management, which is one of the big reasons I'm using Remix in the first place.

A similar discussion already exists here #3955 but it wasn't actually raised as a proposal which is why I decided to start this one separately.

[infiniteluke]

Would something like this proposal solve this issue without leaking the promise? I think it could be applied to useSubmit as well without a useEffect.

remix-run/react-router#9737 (comment)

[jabrks]

I don't think so in my case, as the problem comes from the fact that "complete" function is part of the payload in the event handler that also triggers the submit, so it wouldn't be available when the hook is initialised

[infiniteluke]

What’s in the event that couldn’t be part of the submission? The way I see it, onSuccess could be called with the result of the action function so you could pass through from the submit call to the return to access it in your callback.

[jabrks]

Unless I'm misunderstanding, the complete function itself would need to be passed back and forth between the server and client, as that is only in scope where the submit is called?

[machour]

This got discussed in Roadmap #5, around 31'50

The current idiomatic way to do this today is:

let actionData = useActionData();
useEffect(() => {
    if (actionData.ok) {
       complete(actionData)
    }
}, [actionData]);

We may want to revisit returning promises from action() for <Await />, but for now, this isn't on our radar.

[jabrks]

I agree with the sentiments in the video around this being unidiomatic. My particular use case involves Stripe, and it sounds like another commenter below (@andreafdaf in #5023 (reply in thread)) had also come across a need for this whilst integrating with Stripe, so it may just be that Remix doesn't lend itself particularly well to this unless Stripe choose to offer better support for server rendered React apps. I appreciate the reply nonetheless, so thank you!

[BamMironov]

@machour

The idiomatic way to do this is for your action data to return some sort of information that the submission is complete and you throw that into useEffect.

The approach you described is not an idiomatic way of handling things in React. In fact, it's more of a workaround, and here’s why:

1. useEffect is meant for synchronizing with external systems, as explained in the React documentation. It's typically used for tasks like fetching data, setting up subscriptions (like @jabrks did), or running side effects like setTimeout. Your example doesn’t involve external systems. Instead, you're trying to synchronize one piece of React state with another, which is considered an anti-pattern and should be avoided. The official documentation even states:

If you’re not trying to synchronize with some external system, you probably don’t need an Effect.

2. Why skip a React render before calling complete? There’s no need to involve React rendering just to invoke the complete function. A more logical and natural approach would be to handle the submit Promise directly, like so: submit().then(() => complete()). Breaking this simple operation into two separate steps complicates things unnecessarily. Remember to follow the KISS principle.

[cliffordfajardo]

Someone also mentioned wanting a promise returned from submit here:

• API for hooking into `useFetcher` lifecycle. Ex: `useFetcher({onSuccess, onError, ...})` react-router#10013 (comment)

[andreafdaf]

Hi! It was me.

I've seen this proposal after commenting on yours. From the roadmap talk linked in the previous comment it is pretty clear what is Ryan's point of view on returning promises, and he is totally right that sticking to the React way of doing thing is preferable.

My take on also having promises is that sometimes we are forced into other paths by the libraries we use, in my case for example it is making a payment with Stripe and having to handle 3DS confirmation. Now we are handling it the "Remix way" and it works, but when you see the resulting code it just feels... weird.

Instead of having a clean function that goes on linearly we end up with:

• an onSubmit handler where we await stripe.createPaymentMethod(...)
• if it fails show an error, flow stops
• if it succeeds we fetcher.submit()
• here the flow is broken because we need to jump to a useEffect()

In useEffect() we handle the submission result:

• if it failed we show an error, flow stops
• if it succeeds but we have to show a 3DS authentication we have to await stripe.handleCardAction(clientSecret)
• if this fails we show an error, flow stops
• if it succeeds we need to fetcher.submit() again with our new data
• back to the start of our useEffect() with this new submission

[jabrks]

This is very similar to my use case as well

[kiliman]

Here's a simple useSubmitPromise hook. It uses the existing React Router hooks to manage the request life-cycle.

function useSubmitPromise() {
  const submit = useSubmit();
  const navigation = useNavigation();
  const actionData = useActionData();
  const $deferred = useMemo(() => deferred(), []);

  useEffect(() => {
    if (navigation.state === "idle" && actionData) {
      $deferred.resolve(actionData);
    }
  }, [$deferred, navigation.state, actionData]);

  const _submit = useCallback(
    (target: SubmitTarget, options: SubmitOptions = {}) => {
      submit(target, options);
      return $deferred.promise;
    },
    [$deferred.promise, submit]
  );

  return _submit;
}

// create a *deferred* promise
function deferred() {
  let resolve: any;
  let reject: any;
  const promise = new Promise((res, rej) => {
    resolve = res;
    reject = rej;
  });

  return { resolve, reject, promise };
}

And sample usage:

const submit = useSubmitPromise();

const doSubmit = useCallback(
  (e: any) => {
    console.log("doSubmit");
    e.preventDefault();

    submit({ test: "123" }, { method: "post" }).then(
      (data) => {
        console.log(data);
      }
    );
  },
  [submit]
);

[muchisx]

@kiliman @sergiodxa did you get around to making this an official Remix Utils? I need to wait for the result of an action in another hook before one of it's functions returns and this seems to be the solution. Wanted to check if you have a final gist of it or if this is good enough ?

[seanlennaerts]

@JinYuSha0 why do you set $deferred.current = deferred() after resolving the promise?

[gustavopch]

@seanlennaerts You can't resolve a promise twice. To resolve a second time, you need to instantiate a second promise. Seems like this is the reason.

[seanlennaerts]

@gustavopch in what situation would resolve be called twice?

[gustavopch]

@seanlennaerts The promise is created with useRef, so it's always the same promise along the life of the component. If I understand correctly, you'll only be able to submit once with that promise and you need to instantiate a new promise in the ref so it works if you need to submit again.

[lili21]

same for fetcher.load and fetcher.submit.
sometime you need to do the client-side data fetching to get resource routes data. And it hard to combine it with react-query or swr.