Deprecate non-GET/POST <Form> methods? Or polyfill when scripts are missing/pending/disabled?

[jenseng]

[Edited to include a second proposal]

Spawned from a discussion on this PR.

One of Remix' big selling points is progressive enhancement. <Form>s and <Link>s enhance the behavior of <form>s and <a>s such that they can work identically without / before JavaScript. Occasionally there are discrepancies, but usually they are oversights rather than intentional departures from the spec.

One exception to this is how <Form>'s method can be any HTTP verb, whereas a native <form> is more strict. Although the docs mildly discourage it being used for values other that get/post, it's easy to miss. The risk in using it is a broken user experience if a form is submitted before/without JavaScript. A safer approach would be to use a form data entry to signal branching logic (e.g. submit buttons or hidden inputs with names like intent/action/_method/etc.)

I propose we either:

1. Deprecate the usage of non get/post values, i.e. 1. emit a warning if they are used in dev mode and 2. discourage them more forcefully in the docs. Disallowing them entirely would be a breaking change, though perhaps that could be considered down the road for a major release.

2. Polyfill support for these methods for when scripts are missing/pending/disabled, via a special _method URL param injected into the action URL (details here)

[machour]

I'm 100% with you here.

In addition, to enforce PE, we should make it so all our tests run with and without JavaScript, in order to make sure we stay as close as possible to the platform. Just like you did in your PR 👌

[maxschwarzmueller]

Whilst I do see the "progressive enhancement" advantage, I'm not sure if it's Remix biggest selling point.

To me, the biggest selling point is that Remix offers an amazing way of building fullstack React apps with ease. And it of course benefits from the fact that many browser defaults and standards are embraced instead of reinvented. This leads to less new APIs that must be learned and used correctly.

But I think, it's always great if frameworks offer simple solutions to common problems. And having forms that should update or delete something (rather than create) is a very common problem.

I personally prefer the ergonomics of <Form method="delete"> over adding extra inputs (e.g., <input type="hidden" name="_method" value="delete" />) and handling these input values on the backend.

I prefer having solutions like this:

<Form method="delete">
  <button>Delete</button>
</Form>

export async function action({request}) {
  if (request.method === 'DELETE') {
    // ...
  }
}

over solutions like this:

<Form method="post">
  <input type="hidden" name="_method" value="delete" />
  <button>Delete</button>
</Form>

export async function action({request}) {
  const data = await request.formData();
  const method = data.get('_method');
  if (method === 'delete') {
    // ...
  }
}

For me, a major reason for choosing one framework over another is how easy it is to solve common problems. If "being closer to the spec" actually leads to more work or makes things more complicated, I don't see that as an advantage. After all, there is a reason why I'm using a framework instead of raw HTML, CSS & JS.

[jenseng]

This can be slightly improved by giving the button a name and value, e.g.

<Form method="post">
  <button name="intent" value="delete">Delete</button>
</Form>

... though to your point that doesn't reduce the action boilerplate. I do agree that just using the method is more ergonomic.

[jenseng]

An alternative approach we might consider would be offer "native" support for these other methods, taking a page from Rails' form helpers. The basic idea is this:

1. <Form method> accepts the various additional methods, and embeds a hidden _method input with the value. The underlying <form> renders with method="post"
   • When submitting the form with JavaScript, the user-specified method is actually used in the fetch
   • When submitting the form before/without JavaScript, it's a regular post
2. Before invoking an action handler, Remix checks for a _method entry in formData and adjusts request.method accordingly.

Potential gotchas:

1. Remix would need to look at the Content-Type and unwrap the formData accordingly. This could be problematic for multipart/form-data (e.g. does that mean there would be two passes? what if request.body is a stream? do we need a custom handler to ignore everything but _method?)
   • Alternatively the _method could be put in the action URL params
2. <button formMethod> won't work before/without JavaScript. We could potentially warn against this in dev mode though. edit not a new issue, this is the case today with a JavaScript-enabled <Form>, see here

[sergiodxa]

Another potential gotcha with a hidden input is if for CSS, specifically if you use something like Tailwind space-y-N and space-x-N classes or divide-y and divide-X classes, they will not ignore the hidden input and you'll see an extra border or margin (I had this issue before with custom hidden inputs).

[jenseng]

Amended proposal which might have fewer gotchas:

1. <Form method> accepts the various additional methods. If the method is get/post, the underlying form renders normally. Otherwise it renders as something like: <form method="post" action={`${action ?? "."}?_method=${method}`}>...
   • When submitting the form with JavaScript, the user-specified method and original/default action is used in the fetch
   • When submitting the form before/without JavaScript, it's a regular post
2. Before invoking an action handler, Remix checks for a _method entry in the URL params and adjusts request.method accordingly.

[jamesarosen]

Tailwind's .space-y-N does > * + * { margin-top: N; }. I was unable to replicate the problem here.

But if there is a problem, would adding [hidden] solve it?

<form action={action}>
  <input type="hidden" hidden name="_method" value={method} />
  {children}
</form>

(If not, I'm all for @jenseng's URL-params suggestion 👍)

[jenseng]

One more wrinkle I've just discovered with the existing <Form> behavior; <button formMethod /> only works for get/post; if you set other methods, browsers silently revert it to get:

let el = document.createElement("button")
el.formMethod = "put"
el.formMethod
// 'get'

So although put/patch/delete methods are ergonomic, that's another strike against them.

[brophdawg11]

make it work when scripts are pending/missing/disabled

This is the most important part of the discussion for me personally. I believe there's a base layer of idiomatic Remix that should just work™️ with/before/without JS. I would argue that <Link>/<Form> are included in that base layer and any usage of them should work with/before/without JS. I don't mind the GET/POST limitation personally, but ?method is quite interesting as well. We also have some precedent for inserting elements when you use a certain feature (<Link prefetch="intent">) but I think I probably prefer the other proposed solutions over the hidden input

[sergiodxa]

Also Remix can always allow other HTTP method when using useSubmit and fetcher.submit, since they already work only with JS, you can use JS only features there like using other HTTP methods.

The ?_method is IMO the best solution, Remix already adds ?_data so it's not a new thing.

[MichaelDeBoey]

I'm personally in favor of dropping non-GET/POST tbh, as that makes us work closer to the spec.
Although it's maybe not that much discouraged in the current Form.method docs, we did make sure all other docs use GET/POST & set the submit button's name to 'intent' if necessary not that long ago.

Not discouraging using non-GET/POST would make people also want to use <button formmethod="delete|patch|put" />, which is something we'll never be able to support without a custom Button component on our end & some crazy logic on our end (as perfectly explained by @jenseng above & in #4496 (comment))
We have <button name="intent" value="update">...</button> to support these kind of things anyways, so I would rather make sure the docs are more pushing towards that instead tbh.

So what I think we should do is:

• Keep the current support for non-GET/POST, but add a deprecation warning when people are using them
• Deprecate non-GET/POST in v2

I agree that this would mean non-JS isn't working the same as when JS is enabled, which is something we should fix in most cases.
I do however think we shouldn't fix it in this case, as that would encourage using non-GET/POST more, which is (as I explained above) not a good thing imo.

[jenseng]

A couple ideas to make the emulation more palatable:

1. Remix's default eslint config could include a rule to warn against using those form methods on a native button.
2. Remix could emulate <button formmethod="delete|patch|put" /> through a custom JSX factory. This would be more ergonomic for end-users than a custom <Button />, though it would still have the other downsides listed here and probably some new ones. That said, having a custom JSX factory in place could open the door to some interesting features down the road.

[MichaelDeBoey]

Keep in mind that we're going to support other frameworks as well at some point.
So I think we shouldn't do crazy things like having a custom JSX factory.

It would also mean the code people use is less transferable to other codebasis, which is one of the selling points of Remix: "learn once, apply everywhere" (paraphrased)

[jenseng]

Opened a PR here