Add the ability to change the request within clientAction

[rubber-duck-software]

Admittedly this has the chance to be abused but there are a few scenarios where modifying the request sent to the server might be handy.

For me, I'm trying to save card details on form submit (using stripe) and then send the card-id in the formData to the serverAction.

Right now, this kind of "right before you submit" processing has to be handled with an event.preventDefault() on form submit, which is a shame. Client action provides the perfect place to perform this kind of processing and then hand the request off to the server.

I propose add request as an optional parameter to serverAction. If no request is passed, the server action is called with the same request as client action. If a request is passed, that request is sent to the server instead.

The usage would look something like

export async function clientAction({ request, serverAction }: ClientActionFunctionArgs) {
  const formData = await request.formData()
  // mutate form data here
  // ...
  return serverAction(new Request(request, { body: formData }))
}

[rubber-duck-software]

Stumbled across another use case for this- compressing files client side before sending them to the server. Server's have to have some max request size, but if we can intercept the request to the server and downsample large image files, we can save users a server error.

[brophdawg11]

has to be handled with an event.preventDefault() on form submit, which is a shame

I don't know that I agree - this feels sort of normal to me? You're telling the browser "hey don't do the default thing I want to add some stuff to the payload"? This is how you'd do it without Remix as well:

// With Remix
<Form onSubmit={(e) => {
  e.preventDefault();
  let formData = new FormData(e.target);
  formData.set(key, value);
  submit(formData);
}}>

// Without Remix
<form onSubmit={(e) => {
  e.preventDefault();
  let formData = new FormData(e.target);
  formData.set(key, value);
  fetch(url, { method: 'post', body: formData });
}}>

It feels somewhat less ergonomic to do this through a Remix abstraction IMO. When given a choice, I would prefer leaning on the platform APIs.

There's a related proposal for adding custom headers to the behind-the-scenes fetch request that I think makes more sense because that's something you cannot do through built-in mechanisms.

[rubber-duck-software]

Using event.preventDefault is shame because you can no longer use useNavigation for optimistic UI and loading states. Let's say I want to resize all images on submit - this process can sometimes take a few hundred milliseconds even on a relatively powerful machine. While that is happing, I want to show the form as "submitting".

When I do this work inside of onSubmit with event.preventDefault, remix has no idea the navigation state should really be "submitting".

Moving this task to the clientAction seems like it would somewhat elegantly let remix handle this "pre-server-submission" kind of task.

[brophdawg11]

pre-submission and submitting are not the same thing IMO. You may show them the same way in the UI via let isSubmitting = isPreSubmitting || navigation.state === "submitting" but semantically I sort of see them as different things.

Submitting means data has been (or is actively being) sent to the server and we're waiting for a response. If that state gets interrupted, we know we still need to revalidate since some of that data may have gotten to the server so we need to re-call loaders, etc.

"Preparing" data for submission seems like a worthwhile distinction IMO. That can be interrupted without requiring revalidation etc.

[rubber-duck-software]

Submitting means data has been (or is actively being) sent to the server and we're waiting for a response.

Already, this is not true in Remix. Take the example below

export async function action() {
  return json({})
}

export async function clientAction({ serverAction }: ClientActionFunctionArgs) {
  await new Promise((resolve) => setTimeout(resolve, 4000))
  return serverAction()
}

export default function ClientActionSample() {
  const navigation = useNavigation()
  return (
    <div>
      {navigation.state}
      <Form method="post">
        <div>
          <input name="First name" />
        </div>
        <div>
          <button>Submit</button>
        </div>
      </Form>
    </div>
  )
}

Here, navigation state will instantly transition to submitting, stay there for ~4 seconds and then transition to loading/idle.

Note: navigation state transitions to submitting before we know whether the server action is going to be called.

I would propose a different definition for submitting in remix

Submitting means a POST request is being processed

similarly, loading means a GET request is being processed and idlemeans no request is being processed.

But I think all this is a bit tangential to the proposal. Already in Remix, the navigation state is submitting while we do work in the clientAction. My proposal is about expanding the sort of work which can be done in clientAction.

[brophdawg11]

I mean, sure - client data lets you artificially delay the server HTTP request?

If that state gets interrupted, we know we still need to revalidate

My point here still stands - I see value in the differentiation between actions mutating data and thus requiring revalidation.
Preparing data for submission in a certain format is just a client side transformation - but not yet a submission because nothing needs to be revalidated yet.

It feels somewhat less ergonomic to do this through a Remix abstraction IMO

Another concern of mine here is that opening up full request control in clientAction creates, IMO, weird ways to deviate from colocation and the declarative nature of HTML/Remix:

// my-form.jsx
function MyForm() {
  // This form appears to submit a single `key` field
  // There is no indication that some other file is going to mutate that
  return (
    <Form method="post">
      <input name="key" />
      <button type="submit">Submit</button>
   </Form>
 );
}

// routes/whatever.jsx
function clientAction({ request, serverAction }) {
  let mutated = mutate(await request.formData());
  return serverAction(new Request(request, { method: 'post', body: mutated }));
}

Compared to the current solution available to folks which colocates nicely and sticks to platform + existing APIs:

function MyForm() {
  let submit = useSubmit();
  // This form makes it very clear that it's not just submitting `key`
  return (
    <Form method="post" onSubmit={(e) => {
      e.preventDefault();
      let mutated = mutate(new FormData(e.target));
      submit(mutated, { method: 'post' });
    }})>
      <input name="key" />
      <button type="submit">Submit</button>
   </Form>
 );
}

Anyway, this is the point of proposals, I don't expect you to agree with my view - and happy to see what others have to say here :)

[rubber-duck-software]

In one more effort to win you over (because I think having you advocate for this would go a long ways towards making it happen), I'll phrase the problem another way.

Here is a list of things I can do with client action so far.

1. Do work before calling the serverAction (like invalidate a client side cache)
2. Choose to skip calling the server action (like running data validations on client before sending request to the server)
3. Modify the data received after calling the serverAction (not sure what the use case is, but it's possible).
4. Have no server action and do work only on the client (perhaps saving data to localStorage, calling into a web worker, etc.)

Maybe there's more, this is what came to mind for me.

I guess this request stems from a more basic pain point- namely I cannot simply use fetch() to call my server action if there is a component defined on the route. This means a client action like below isn't very easy (impossible?) to write.

export async function clientAction({ request }: ClientActionFunctionArgs) {
  const formData = new FormData()
  formData.set('lastName', 'Name')
  const res = await fetch(request.url, {
    method: request.method,
    body: formData
  })
  return res.json()
}

Sending a request from a client action to a server action is hard. For that matter, sending a request from a clientAction to a server loader is hard.

We are given useFetcher to make it convenient to call the server within a component, but we have no API making it convenient to call the server inside of clientLoader and clientAction.

My particular use cases aside, I think clientLoader and clientActions should be able to call serverLoaders and serverActions with ease. Perhaps the API for this should look different than my proposal, but I think the parallel API to useFetcher which works in client loaders/client actions would be quite valuable.

[gustavopch]

Another concern of mine here is that opening up full request control in clientAction creates, IMO, weird ways to deviate from colocation and the declarative nature of HTML/Remix:

I guess that won't be much of a problem when using React's new client action syntax <Form method="post" action={clientAction}>. I mean, when you see the form, you'll know there's a client action attached that may influence its behavior.

[rubber-duck-software]

Just thought of another use case for a capability like this. A clientLoader should be able to signal the server loader not a fetch a certain piece of data (presumably because we have it in client side cache).

One natural way to do this would be for the client loader to modify the request sent to the server loader (add some query param or header or some such) which tells the server loader to skip some piece of work.

The client loader would then stitch the server response together with what it has in the client side cache.

[rubber-duck-software]

@ryanflorence I'm thinking of this video you did https://www.youtube.com/watch?v=5DZ3D7xj6QY

For other readers' benefit, in the video Ryan describes how a clientLoader can be used to serve search results from a client side cache.

The clientLoader checks if we have the list of movies in a client side cache

• if so, serve results from the cache and do the filtering client side (no request to the server needed!)
• if not, fire a request to populate the client side cache and serve the results from the server.

This is a really neat trick enabled by Remix. Truly astounding!

...but I think it could go further. Let's say the serverLoader for this page returned more than just a list of movies. Let's say the loader returns a list of ids for movies the user has favorited. Let's further say that fetching the user's favorites is really fast and we don't want to store it in a client side cache.

Now we have a dilemma - I want to return filtered movies from client side cache, but I still need to hit my serverLoader to get the list of user favorites. Further, when I try to get the list of user favorites, the serverLoader will also do the search of movies, so my client side cache isn't actually saving me anything any more. This is a bummer- either the entirety of a serverLoaders response should be in client cache or none of it. You don't get any savings if you only cache part of it.

Now imagine a world where something like the below was possible

export async function clientLoader({ serverLoader, request }: ClientLoaderFunctionArgs) {
    if (!memory) {
        replicateMovies()
        return serverLoader()
    }
    
    const newParams = new URL(request.url).searchParams
    newParams.set("skipMovieQuery", "true")
    const serverResultPromise = serverLoader({ search: newParams.toString() }) // would need to workshop the syntax. This syntax probably isn't workable. 
    
    const movies = await getMoviesFromMemory(request)
    const serverResult = await serverResultPromise
    return { ...serverResult, movies }
}

Now, we were able to save significant time on the server (didn't have to query movies), and we were free not to store the user's favorites in cache. This added flexibility is important for complex pages which need lots of data (only some of which makes sense to cache client side).

The added complexity could be totally opt in. Kinda like optimistic UI- it only makes your code more complex if you take time to do it, but its a super powerful framework capability for sites that care about it.

[sergiodxa]

Some scenario where you may want to add more data to the serverAction, if you're using location.state, you can now access it with window.history.state inside the clientAction, but there's no way to add it to the data sent to the server.

And while you could use useLocation().state and render a hidden input with that data it could be useful to add more things directly in the clientAction too.

[nikita-starostin]

Though not a critical, but looks like logical improvement to me for existing stuff.

From my DX for me just easier to do all the work in one place (client action), rather splitting it between clientAction and component code.

My use case:
I have lot of pages and every pages renders a form. That forms are representing one global state object. I am using clientAction to manage global state and redirects, and at some point of a time a need to submit global state to server action. The issue that global state is updated in clientAction, so for now I am making smth like.

export function clientAction({ serverAction, params }) {
     if (params.stateId == 'submit') {
        return serverAction();
    }
    globalState.update();
    redirect ("/theSameRoute/submit"); // instead I would like just pass new state to server action
}

export function clientLoader({params}:{params}) {
    return { stateId: params.stateId };
}

function TheSameRoute({stateId}) {
    const submit = useSubmit();
    useEffect(() => {
        if (stateId === 'submit') {
           submit({ state: globalState.toString() })
       }
    }, []);
}