Support JSON with useFetcher.submit()

[byudaniel]

It would be handy to have the option to submit arbitrary JSON with useFetcher.submit(). I've got a very complex form with nested arrays that I could technically force everything into hidden fields and use <Form ...>, but for this use case feel that submitting JSON would be cleaner. Currently the behavior serializes an object into FormData, which is turning an array into [object Object].

Are there any plans for something like useFetcher.submit({ myComplexData: [{...}] }, { method: 'post', encType: 'application/json' })?

[ccssmnn]

Have you considered using the JavaScript Fetch API?

[byudaniel]

Yes, I'm doing that as a workaround, but it would make sense to include it within the useFetcher API too.

I had come across this thread and had assumed it was a supported scenario.

[ccssmnn]

From the Remix docs here you should be able to do this already. The advantage of this over the JavaScript Fetch API is, that you get all the utilities for building UI depending on your request.

function SomeComponent() {
  const fetcher = useFetcher();

  const onClick = () =>
    fetcher.submit({ some: "values" }, { method: "post" });

  // ...
}

Is this what you were looking for? Otherwise you might need to specify your question.

[byudaniel]

fetcher.submit({ some: "values" }, { method: "post" }); will serialize shallowly as FormData, so if you have a complex object it won't be serialized correctly.

useFetcher.submit({ myComplexData: [{...}] }, { method: 'post' }) will send as FormData with myComplexData=[object Object].

[byudaniel]

The submit function only accepts simple objects with string values, see

remix/packages/remix-react/components.tsx

Line 999 in 5e16c82

| { [name: string]: string }

.

[meglio]

It got updated since then. It can now take a whole lot of different types as an input, including FormData:

[kiliman]

I've added a patch to add native JSON support to useFetcher(). I think this will help transition existing apps to Remix where there is heavy use of JSON APIs. The DX/UX of useFetcher state handling makes this superior to using plain fetch().

export const action: ActionFunction = async ({ request }) => {
  const data = await request.json()
  return json({ result: { success: true, message: 'ok' }, posted: data })
}

export default function () {
  const fetcher = useFetcher()
  const data = fetcher.data
  const handleClick = () => {
    fetcher.submit(null, {
      action: '?index',
      method: 'post',
      json: { hello: 'world' },
    })
  }
  return (
    <div>
      <h1>useFetcher with JSON</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
      <button onClick={handleClick}>Fetch</button>
    </div>
  )
}

https://github.com/kiliman/remix-json-fetcher

[jacob-ebey]

What about the API:

fetcher.submit({ json: "values", go: "here" }, {
  action: '?index',
  method: 'post',
  json: true,
})

It feels strange to pass null where the "body" currently goes and have a config key for the JSON (body) to me.

[kiliman]

I was just trying to be minimal in my patch. The function was already doing a lot with the initial parameter. But I'm not tied to the API. So whatever works best is fine. We just need a way to indicate this is a JSON request. We could even overload encType to support application/json.

My original method was to do something like this, to be more explicit and match fetch(), but added too much boilerplate:

fetcher.submit(null, {
  action: '?index',
  method: 'post',
  body: JSON.stringify({ hello: 'world' }),
  headers: { 'content-type': 'application/json' }
})

[gabimor]

+1 for sending the json object as the first parameter

[lili21]

it doesn't work for the 1.11.0+ version.

[kiliman]

I submitted a PR to add this feature to fetcher.submit()

#1990

[ryanflorence]

Since the beginning I've been considering different enctypes for <Form>, and all of its cousins: submit(), fetcher.Form, fetcher.submit().

So if I were to propose anything around this, the API would just be encType:

Enctype all the things

// Form API, any inputs w/ the same name become an array
<Form method="post" encType="application/json">
  <input name="email" />
  <input name="password" />
  <input type="checkbox" name="brand" value="nike" />
  <input type="checkbox" name="brand" value="adidas" />
</Form>

// useSubmit API, just plain JSON
submit(
  { email, name, brand: ["nike", "adidas"] },
  { method: "post", encType: "application/json" }
)

And of course, fetcher.Form and fetcher.submit would be the same.

My hesitation here is progressive enhancement, particularly early clicks. We can't just ignore it because w/o JavaScript the browser will ignore the invalid form enctype and send it as "x-www-form-urlencoded". We also can't easily prevent those clicks without getting really weird.

Only work with submit not form

If we only support "application/json" for submit and fetcher.submit then we don't have to worry about the early click problem.

This is probably the way to go.

export function action({ request }) {
  if (request.headers.get("Content-Type") !== "application/json") {
    throw new Response("Unsupported Media Type", { status: 415 });
  }

  let json = await request.json();
  // carry on ...
}

export default function SomeRoute() {
  return (
    <button
      onClick={() => {
        submit(
          { email, name, brand: ["nike", "adidas"] },
          { method: "post", encType: "application/json" },
        );
      }}
    />
  );
}

Back to lots of client state

I've got a very complex form with nested arrays

One huge benefit of using HTML forms and FormData is that you can skip a ton of React state and let the DOM just deal with it. If you're getting values from the user you're now in charge of turning everything into controlled components and managing a bunch of React state to create that JSON object.

Is it worth it? I'm not convinced it is.

This usually comes up when migrating to Remix where you already had a ton of React state to build the object and did your own fetch. In those cases it's easy enough to dump all the JSON into a field and parse it on the server back to JSON:

<input type="hidden" name="json" value={JSON.stringify(values)} />

// in the action
let json = JSON.parse(formData.get("json"))

If you take the time to refactor to form fields, I think you'll find you get delete a bunch of code and don't have to manage nearly as much state.

Also, don't forget that formData already supports "arrays" by naming the fields the same things and using formData.getAll().

Anyway, I'm not opposed to this, but I personally need to see some examples of real world use cases that contrast both approaches. My gut tells me most folks will see the normal forms version and prefer it over managing all the form state manually to build up a JSON object.

[dan-cooke]

Enforcement never works...

Wrong choice of words. Rather “recommending” form data is a great way of preventing framework users from shipping too much code.

obviously it cannot be enforced, users will always find ways around it

[adanielyan]

And I'm sure that's a valid recommendation for many (maybe most) use cases. But having an alternative for other use cases, while still recommending the form-data way, would be much more helpful. That's exactly the difference between enforcement and recommendation. You give people a recommendation and an option not to follow it if they don't want to.

[dan-cooke]

hence why i said

but I suppose it can’t hurt to support it for the cases were formdata is not a great fit

In my OP

[kiliman]

Since this is something that can be easily accomplished in userland, I don't think they'll modify the API to support native JSON.

Just create your own hook, useJsonFetcher.

[lili21]

@adanielyan - in our app we don't use Remix's <Form> component at all because we use the <Form> component of the component library, so we use submit function a lot

Wouldn't useSubmit or usFetcher's submit function solve the JSON problem?

const function handleDragEnd = () => {
   fetcher.submit(
      { intent: "__update-user", body: JSON.stringify({ .....someData....}),},
      { method: "post" }
   )
}

It's still formData at network level. some in-app webview doesn't support sending formData

[dan-cooke]

Is this a good idea?

When I first started using remix - this feature was something that I kept asking "Why didn't they implement this?" - but the more I used remix, I soon realised. This is by design.

Now I'm on the opposite side of the fence - I don't think this should be supported at all.

Why FormData is all we need

Its often said that a well designed language, framework has an established way of doing things - ideally a single way to do anything.

Well for handling user input remix has this sorted (or shall I say HTML had this sorted years ago, but we all forgot) - FormData and HTML Forms

Coming from a modern React application, our natural instinct is to turn our noses up at the use of <form> and FormData, its like the Rust compiler, at first you hate it - but you soon realise its just trying to help you.

If Remix adds first class support for Form JSON data type, it would encourage bad practices, in the use of controlled components and complex react state.

Why supporting JSON encType would lead to bad habits

It would allow developers coming from traditional react applications to merely use useSubmit or useFetcher.submit - pass it their massive state object with complex nested arrays, set encType: 'application/json' and wipe their hands with it. It will just work.

FormData is not so lenient. Nested arrays / objects are a no no with form data (or at least they aren't easy to work with). So you are forced to rethink your structure.

A recent example of mine

I was building a Step (Wizard) form. I built it with the typical React way, a huge state object tracking changes the user made at the top level. This object had multiple levels of nesting, and nested arrays. In order to even get this object sent to my action function, I had to really do some mental gymnastics - I had to use fetch and post to the route. It felt dirty, it felt hacky, it felt like I wasn't supposed to do that. It got me thinking - maybe I should do this differently?

So I decided to completely isolate each page in the wizard, use HTML forms entirely, and store the progress of the wizard in session storage.

After my refactor I looked at the code diff, I had cut down the amount of code by almost half -not only that, but I am now shipping less to my users, I was able to remove recoil and react-hook-form. And I get the added benefit of working without Javascript.

Now I look back, and I am just in awe at the remix design philosphy - it made it difficult for me to do it "wrong". This is how frameworks and languages should be designed, the benefits should be abstracted away from you - you should get them for free, without thinking. Just by following the most basic standards.

Edit: so I think I have changed my mind minorly - I do think JSON should be supported now after reading various use cases on this thread. But I would be in favour of putting it low down in the docs and guiding people towards FormData for 90% of use cases

[IHIutch]

Can someone ELI5 FormData for me in this case? I read this:

It would allow developers coming from traditional react applications to merely use useSubmit or useFetcher.submit - pass it their massive state object with complex nested arrays, set encType: 'application/json' and wipe their hands with it. It will just work.
FormData is not so lenient. Nested arrays / objects are a no no with form data (or at least they aren't easy to work with). So you are forced to rethink your structure.

And think, if it "will just work", why not support it? So that leads me to wonder: In what ways is FormData so superior that working with JSON becomes an anti-pattern?

Would love to learn more, thanks.

[IHIutch]

That's a helpful explanation, l appreciate you taking the time. If I'm understanding correctly, it seems that the recommendation toward using FormData is because it's a native web experience (via forms) where sending JSON is not. So in that sense JSON becomes the anti-pattern because it requires additional overhead to support?

(Putting my PHP hat on, this seems to make sense to me)

[IHIutch]

Following up here, the Remix docs pretty much address this in the FAQ: https://remix.run/docs/en/v1/pages/faq#how-can-i-have-structured-data-in-a-form

So while it's not technically JSON, you can still create a nested data structure and handle the parsing with a library like query-string. Given what's been mentioned before, that probably feels like an appropriate compromise while maintaining the integrity of "the platform"

[iway1]

Not going to argue about how absolutely wacky it is to not support JSON, just going to ask if could you at least change the docs to make it clear only form data is supported. The example given just shows passing an object and doesn't point out that actually you have to pass form data: https://remix.run/docs/en/v1/api/remix#usefetcher

Scroll down to fetcher.submit

[IHIutch]

You can submit the JSON as the example suggests, but it needs to be accessed via FormData in your Action.

Though I agree, this section of the docs aren't super clear to newcomers. Perhaps showing the Action receiving the data could help clarify.

[iway1]

Yeah, that would help a lot. Making Remix documentation more accessible would help with its adoption and save future devs some time (would've definitely saved me a bit of time).

I was getting a type error trying to pass an object as well which made me think I had to pass FormData to submit. Is that a bug with the typing? or does submit only allow string values ? My object was something like:

const o = {
    value: "Hi",
    numberValue: 5,
    boolValue: false
}
fetcher.submit(o, {method: 'post', action: '/something'}); // type error

I could do //@ts-ignore and it would submit, but feels bad man. If submit only likes string values that would be another great thing to include in the docs.

[lili21]

I get the point. Personally, I like FormData, I like the progressive enhancement philosophy.
But in reality, FormData is not always an option. I'm building a project with remix right now, and the project needs to run inside App's Webview. and it doesn't support FormData for some security reason. I have to change it to JSON.

[barbinbrad]

As far as I understand this problem (forgive me for the ignorance) -- there is currently strong typing of data from loader to client, but from client to action the typing is not as strong. This is because formData can be a string or file.

The thing that brought me to this discussion was that I want to send a number from the client to the action without having to do parseInt inside the action.

A nice workaround seems to be:

Client Side

const handleTeamSelect = (team: Identity) => {
    const data = new FormData();
    data.append("json", JSON.stringify(team));
    submit(data, { method: "post" });
 };

Action Side

export const action: ActionFunction = async ({ request }) => {
  const data = await request.formData();
  const identity = JSON.parse(data.get("json") as string);

  const identitySession = await getIdentitySession(request);
  identitySession.setIdentity(identity);

  return redirect("/home/overview", {
    headers: { "Set-Cookie": await identitySession.commit() },
  });
};

But even with this workaround, identity isn't strongly typed in the action.

[dan-cooke]

I tend to use a validation library like zod to validate form data. Parsing form data with a validator like this results in strong typing of your data

[barbinbrad]

Ahh, thanks so much! I see this sample repo, after grepping for zod: https://github.com/remix-run/remix/blob/cde451c5c1cc6dcaff74b8e6b4b7bf2e978ed2ec/examples/io-ts-formdata-decoding/README.md

[dan-cooke]

Awesome, I came across that example with io-ts before but haven’t tried it out.

I personally use a combination of remix-validated-form and zod-form-data.

But I like the minimal boilerplate in io-ts

[barbinbrad]

I've been using this suggestion for ~six months now. I can't recommend it enough! Thanks again @dan-cooke

[Klavionik]

Just wanted to add my 5 cents to the discussion. I understand the dev's point about nested data structures. However, what bothers me right now - how do we send a null to a server using FormData, if null is going to be converted to an empty string?

Imagine we have such a case, when there's some REST API, and we need to update the entity's state with a PATCH request, sending something like that:

// PATCH /entity/1
{"expirationDate": null}

Why would we do that? For example if we have the expirationDate field of the entity set to some date and we want to "reset" it, effectively making the entity non-expirable. Our API doesn't accept empty strings, it considers them badly formatted dates. Only ISO 8601 strings and null are valid.

I've seen this pattern many times and as far as I understand, Remix (and React Router v6, which I'm trying to use) Actions don't support such cases.

I'm sorry, if I'm missing something, but I wanted to point out this particular pain (I didn't find any earlier mention of this).

[allansson]

I think that if you don't set the name of the input or set it to empty, then the field will not be sent during submit. FormData.get will return null if a field does not exist.

// Client
<input name={expirationDate === null ? '' : 'expirationDate'} value={expirationDate} />

// Server
const expirationDate = formData.get("expirationDate");

It is verbose though. You could always wrap the logic in a component to make it more readable.

[Klavionik]

Thank you for your suggestion, but it doesn't help in the described case. One need to specifically send a null value. Not sending the field at all just won't change the state.

[meglio]

I ended up using fetch() directly and ditching the beauty of the built-in useFetcher(). Unfortunately, but I'm forced to not use this Remix feature because of its design and restrictions.

[kiliman]

There's a new proposal for supporting different encType for serializing data. This includes support for application/json

Better actions with opt-in serialization of payload data
remix-run/react-router#10324

[vaynevayne]

1. No one will use raw input to write pages,
2. Most component libraries support value onChange controlled mode,
3. Generally, react-hooks such as useForm are used to manage the state of the table, so the controlled mode is the simplest.
4. As far as I know, people who write frameworks rarely touch composite business, so please keep the normal state in the design library, and don’t add too many personal ideas
5. for formData i There's a reason why people don't use things that aren't popular, it is not family for devtool, it is too terrible

[ZeldOcarina]

All right I guess I'll resort to good old Axios and setting all the loading states manually! 😅
I still think it's weird to force users into that, I understand the principle, but json is also a native web feature, not being willing to support it is just weird, I use plain forms in 90% of my apps but when I have nested forms to create collections of very complex data it's just not ergonomic to do that..

[ttsirkia]

Yes, kind of. You just need to omit the information on that page and check the other page.

[ZeldOcarina]

Wanna propose a change? I would add a paragraph directly in the methods section specifying that.

[ttsirkia]

I can make a PR. The best place would be here?

Something like this:
Object can also be any JSON data if you pass encType: "application/json" option. See more details in useSubmit documentation.

[ZeldOcarina]

Oh yeah that would make sense!!

[ttsirkia]

PR #8787