[RFC] Two methods for useFetcher to work without javascript

[nickjs]

Hi Remix friends,

A question I've seen pop up several times in Discord (including asked by myself!) is "how do I submit a form of a child resource on my parent reosurce page without causing a navigation?" The answer is of course useFetcher, and the useFetcher docs include an example of how to do exactly this via a resource route.

As noted in the docs, if your resource route only returns json or a status code, your page will no longer work with javascript disabled because the form will cause a whole navigation to the resource route, which doesn't render anything. The docs currently propose exporting a default component from your resource route that will only be seen when js is disabled. While this works, it feels like a smell to me. 1. It's an extra component to write and maintain that will very rarely be used, and 2. there isn't always a component that makes sense to export from a resource route.

For example, in my app, I have a Note model that is polymorphic across many different models. E.g. a Vendor has many Notes, as does a Product and a Customer. I have routes for /vendor/$id, /product/$id, and /customer/$id, which each render (among other things) their list of notes, but I do not have a standalone notes UI as they can't really exist on their own. Each of those pages that has a list of notes has UI for editing, deleting, and starring those notes, so I've created a resource route for each action: PUT /api/notes/$id, DELETE /api/notes/$id, PUT /api/notes/star, and then I invoke those actions using useFetcher from the parent pages.

There's nothing I could export default from /api/notes/stars to render that would make sense, and as long as javascript is enabled and we're using useFetcher, I don't want to trigger a navigation since these are "child resources" on the "parent" route.

So I propose two options that will allow developers to have resource routes with no default export but that will still work with useFetcher().Form with javascript disabled:

Solutions

1. Have useFetcher() automatically set a header when creating its fetch request that says "yes, this request is originating from javascript". Something along the lines of X-Remix-Fetcher: true. This would allow the developer to check the header in their resource route actions and conditionally return either json() or redirect() based on if the request is a js fetch request or a full HTTP navigation. For example:

export let action = ({ request }) => {
  // do action stuff
  if (request.headers.get('X-Remix-Fetcher') === true) {
    return json({ok: true}) // or json({errors})
  } else {
    return redirect('/wherever`)
  }
}

2. Add a configuration option when creating a fetcher to tell it not to follow redirects, for example: let fetcher = useFetcher({ followRedirects: false }). This way, our resource route actions can just always return a redirect without having to know anything about how the request is originating, and the client controls whether the page navigates to that redirect or not. We could also possibly make this the default behavior and not be an option, but to be honest, I think I would personally find that more surprising than a fetcher following an explicitly-returned redirect.

Personally I think I prefer option 2; it requires setting the option every time you create a fetcher, but option 1 requires adding conditional logic to every resource route. More importantly, option 2 leaves the client in control of when it should navigate vs when it should not without having to share details about the user's browser to the server.

If people think either of these are a good idea, I'll be happy to open up a corresponding PR! Thanks in advance.

[kentcdodds]

Have you tried redirect(request.url)?

[nickjs]

@kentcdodds Thanks for the suggestion! Unfortunately that would still trigger a navigation when the resource route is called via useFetcher with js enabled. Even though useFetcher is supposed to call actions without navigating the page, if your action explicitly returns a redirect, useFetcher will still follow it.

In my particular case it 500's because the request.url is the resource route with no default export, but even in more general cases, you'd still want to be able to handle redirects and json responses in the same action.

[kentcdodds]

Oh right. What about redirecting to the page that's making the request? You should be able to get that from the referrer header or even include a hidden input with a redirectTo form value

[nickjs]

Yup I can do that, but still the same issue. As long as the user has js enabled, I don't want the fetcher to navigate at all. Perform the action, get the json response, rerun the loaders, but leave the user exactly where they are. And that works great as long as a) the user has js enabled, and b) the action does not explicitly return a redirect.

This RFC is specifically to handle the user experience for users that do not have js enabled without lessening the experience (via causing a navigation) for those that do have js enabled.

And to be sure, Remix definitely prefers the pattern of 1:1 action->route so the route can just call its action directly. But as people continue to build bigger apps with Remix, I believe they're definitely going to want to call separate actions for hasMany-esque child resources without navigating the page, e.g. deleting or favoriting a Note for whatever parent resource the user is currently viewing.

[kentcdodds]

I'm not sure that useFetcher is supposed to follow redirects 🤔 maybe related to #1220 (comment)

[nickjs]

The plot thickens! Thanks @kentcdodds. I'll watch that issue and if it is indeed a bug and not desired behavior then I'll close this RFC.

Though I still maintain that if I'm a new Remix dev guessing about least surprising behavior, I'd probably be least surprised that a fetcher does follow an explicit redirect. But that's a pretty weakly-held opinion.

[ryanflorence]

add a form field with JavaScript instead?

[nickjs]

Sure, that would have the same effect as adding a header in my suggested option 1.

But making the dev explicitly add a hidden input to every single fetcher (or at the very least form) feels like a worse DX to me.

That said, I still prefer option 2, which is an even better DX. Injecting either a header or a hidden input means the developer still has to care about it and add conditional logic to every resource route for what feels to me should be a client side only concern.

Definitely happy to be convinced otherwise!

[ryanflorence]

When you're using "api routes" with useFetcher you've already bailed on the "no javascript" use case. This isn't a religious thing for us, we don't believe every interaction should work without JavaScript. If you do, you have the tools to make it work :)

If you don't want to repeat yourself, wrap useFetcher with your own useFetcher that adds the field and use that everywhere.

I don't think I'd ever want option (2), it makes protecting routes behind auth too complicated to handle both document and fetch requests. If you really want something like that, use a resource route (loader/action + no component) and call it with fetch yourself instead of useFetcher. useFetcher is a "Remix UI-aware fetch", it revalidates data, can redirect the app, etc. A resource route called with fetch is just a plain api route that you're used to in other frameworks.

[nickjs]

Hey Ryan, sorry to leave this hanging, I wanted to play around with different options to make sure I'm not wasting your time. I've tried out about a dozen versions of this workflow now and landed exactly where you did: there are a lot of potential workarounds to implement the type of behavior I described, but the only one with no edge cases in both js and no-js is to inject the hidden form field with JavaScript.

I would love to live in a world where useFetcher would allow you to pass headers, but that would create a very sneaky edge case where those headers are missing if the user has js disabled and the submit happens via a plain HTML form submission.

One last question that popped up as I was researching this: is there a practical difference between <fetcher.Form action="foo"> and <Form action="foo" replace> when js is enabled?

Please consider this RFC closed; I would close it but it doesn't look like that's an option for Discussions 🤔. Thanks for considering it and thanks for Remix!

[sergiodxa]

<fetcher.Form action="foo">
That will do the submit without causing a navigation.

<Form action="foo" replace>
That will create a navigation, but it will replace the current entry on the history stack with the new one after the navigation so the user can't go back.

[kentcdodds]

Importantly, the user can't go forward when you replace either. So if the user goes back then submits a form that replaces then they can't go forward because that "branch" of history was replaced with a new one that doesn't have a forward.