Form navigation state

[jacob-ebey]

A pattern that exists today for optimistic UI's consists of using hidden inputs to gain access to data only needed client side. If we could introduce a "state" concept for form submissions, or piggy back on the router state, we could remove unnecessary fields from being serialized over the network.

Something like:

const navigation = useNavigaton();
// formState would be the new property containing the temporary state for the submission
const { some } = navigation.formState || {};
// some == "values" when form is submitting / revalidating

return (
  <Form state={{ some: "values" }}>
   ...
  </Form>
)

[ryanflorence]

Ahh! I've been thinking of this too. Little values to identify a form submission that you don't want to actually go in the formData. As a gut reaction, I like this.

I've also wondered about useForm() return a form component that returns the navigation info but only for that form.

let [Form, { formData }] = useForm();

// normal form API
<Form />

// but `formData` is only populated when *this form* is being submitted

[mjackson]

I’m not familiar with this pattern. Would you mind helping me understand with an example of how people normally use this to build optimistic UI? 🙏

[ryanflorence]

The distinction to me is "server data" vs. "ui data".

Right now you have to put UI data in the form so that other parts of the UI can respond optimistically. That stuff goes to the server for no reason. Database doesn't need it, but the optimistic UI does.

It would also be useful for shouldRevalidate. You could easily identify a specific mutation with some form location state instead of (again) checking for some formData that the action doesn't actually need. I often have to add random formData for shouldRevalidate.

From a strictly technical API symmetry perspective, we talk about <Link> and <Form> as two sides of the same coin. <Link state> exists but <Form state> does not, but they both create a new location. In my code I'd use this all over the place instead of pointlessly sending it to the server.

[ryanflorence]

Sorry, there were no examples there.

Granular Busy Indicators

Consider the simplest case of indicating that a form is being submitted by having the submit button text change from "Save" to "Saving...":

function EditContact() {
  let navigation = useNavigation();

  let busy = navigation.state === "submitting"

  return (
    <Form method="post">
      <button type="submit">
        {busy ? "Saving..." : "Save"}
      </button>
    </Form>
  )
}

This is fine until there are two forms on the page, like a sidebar that has forms in it, like the React Router tutorial:

If you click the "New" button on the left while looking at the edit form, the button on the edit form will say "Saving...". Which is weird because that's not the form that is saving.

Today, we fix this with a funny hidden form value that's only for the UI and not the server:

function EditContact() {
  let { formData } = useNavigation();

  // now we know that *this* form is busy, not just any random form
  let busy = formData && formData.has("editingContact")

  return (
    <Form method="post">
      {/* 👇 only for the UI, not the action */}
      <input type="hidden" name="editingContact" value="" />
      <button type="submit" disabled={busy}>Save</button>
    </Form>
  )
}

With <Form state> we could do the same thing w/o polluting formData with values that don't matter for the action.

function EditContact() {
  let { formState } = useNavigation();

  // now we know that *this* form is busy, not just any random form
  let busy = formState && formState.editingContact;

  return (
    <Form method="post" state={{ editingContact: true }}>
      <button type="submit" disabled={busy}>Save</button>
    </Form>
  )
}

Revalidation Conventions

It would also be useful in shouldRevalidate. I often add one of these fields to only revalidate if some key like "contacts" is present, like a cache key so multiple forms can mutate "contacts" and this shouldRevalidate will only revalidate if that key is present:

export function shouldRevalidate({ formData }) {
  return formData.get("revalidate_key") === "contacts";
}

With form location state I wouldn't have to pollute every form with that field being sent to the server:

export function shouldRevalidate({ formState }) {
  return formState && formState.revalidateKey === "contacts"
}

[ryanflorence]

Side note: My assumption that we'd do it with location.state is probably wrong, because that would persist when you POP to the location but the form isn't actually busy anymore, leading to incorrect UI states.

[juanpprieto]

An example:

AddToCartButton -> sends variantId and quantity as hidden inputs to the cart mutation action (just what the mutation needs).

CartDrawer -> To optimistically render this new line item, we need more than the variantId and quantity. We also need say imageUrl, title, price.

Since the mutation can be initiated from a collection or or a product page, we have no way to get this additional product info. So, we have to pass them also as hidden inputs, so we can capture them in the CartDrawer via fetcher.submission.formData

[ryanflorence]

Ha! Yes, I remember when I was implementing "add to cart" in Snow Devil myself I put every one of those fields you mentioned in the formData so I could optimistically show it in the cart.

[brophdawg11]

Maybe somewhat tangentially related but would we be open to exposing the navigation state to loaders/actions (React Router only)? That combined with this proposal would (I think) provide a nice solution for remix-run/react-router#9367, where the use-case is effectively:

• I'm running a SPA
• I have a complex object to submit to my action
• I don't want to serialize/deserialize that object through FormData

async function action({ request, state }) {
  await process(state.complexObject)
  return { ok: true }
}

function Component() {
  let complexObject = useDataFromSomewhere();

  return (
    <Form state={{ complexObject }}>
      <button type="submit">Submit</button>
    </Form>
  );
}

[kiliman]

Wouldn't that be an issue when migrating from RR to Remix SSR? The whole point of this state is to NOT send it to the server. So server based actions would NOT have this object?

Is there any other part of RR 6.4 where the data handling will be different from Remix?

[brophdawg11]

oops - yeah I should have clarified this would only be for React Router loaders/actions, not Remix. Basically now that we have the Remix APIs in RR, we'll probably start to find some cases where we can do things slightly differently when our loaders/actions are not on the other side of a network.

If we ever did the clientLoader thing in Remix then this could be leveraged there as well: #2853