React router's data utilities are awkward in SPA's

I've been having some FOMO with Remix and Next.js lately. The company I work for was contracted to develop the frontend UI for an internal application of a large public business. I lead that development. I've been in this position for this same app for years now. They wanted a single page app that they could host and serve statically. They have people on their side doing the development of the api's that the frontend will be consuming. We started the app using react router v3 and have upgraded it to v6 now. We've also gone through an evolution of using redux/redux-thunk and now react-query for our data fetching.

I've recently been given the opportunity to start the UI development of a new application and although the requirements are the same in that it needs to be a SPA, I was excited to use react router's new data utilities: loaders, actions, and fetchers...and then I realized just how awkward these things are in a single page application.

In this post I'm going to describe what I find awkward and then describe the approach I've decided to use on this new application. I hope this helps other devs and comes across as constructive criticism and useful feedback for the Remix team. I have a ton of respect for those folks. I love react router and am very grateful for the work that's been put into it.

Route loaders

I dig route loaders. The idea that the router can fetch each active route's data in parallel to avoid waterfalls makes a lot of sense to me. You fetch the minimal amount of data for each route here. If certain data isn't immediately integral to a particular route, then you can go ahead and render it and fetch the other data after the route component is rendered. Beautiful.

Dominik(aka tkdodo) has an excellent post on how to incorporate react query and react router. I highly recommend giving that a read. queryClient.ensureQueryData() FTW!

Fetchers

This is where things start to get weird. Fetchers are used to make requests to apis without triggering navigations. For example, fetching options for autocomplete/combobox inputs would be an appropriate use case for a fetcher. It's similar to react-query's useQuery and useMutation hooks.

What I have found awkward is that you must go through the router to use these. React router wants to be able to invalidate these requests after successful action submission. That doesn't sound so bad but let's look at what's required to make a fetcher work.

Let's pretend we're implementing a combobox where a list of cities populate as options as the user types. At a minimum this is what our router could look like:

So what's awkward with this?

First off, we're defining a sort of "virtual" route. It doesn't really exist. You can't go to /cities in the browser and get that data because this is a single page app. This works as expected with Remix. You can go to /cities and get that data back. With react router you get an error about the route not returning an element. This makes sense. React router has no way to actually return a Response to the browser with the Content-Type: application/json header set.

Second, we can't just make requests directly from our route element to the endpoint that we need. We have to go through the fetcher api which means using fetcher.load() or fetcher.submit() which means we are beholden to either using search params or FormData. I'd guess the vast majority of the api's people are consuming in react router apps are using json or graphql. We have the mental overhead of conceptualizing two requests: one to the router and one to the api endpoint we actually care about. In the example above, we use a contains search param because that's the simplest way to pass the data. However, the api endpint we're using uses json. We have to juggle this request through react router using different content types to make it work.

Third, if you're using react router's actions you must implement the /cities route's shouldRevalidate if you don't want the router to retrigger this after a successful action:

Fourth, if you have some data you want to fetch that's not crucial at initial route render, the recommendation is to use useEffect to trigger that.

The is less than ideal because it triggers the fetch twice when being run in strict mode. When you're hacking on your app, you'll see two network requests due to this. Is it really a problem? The fetcher will appropriately handle the responses and give you the response from the second request but I think this makes it harder to find legitimate bugs, where your code could be errantly making duplicate requests. That said, it is a recommended approach seen in the reactjs docs.

You also have to reach for useEffect when the fetcher.data lands like to do things like focus an input or set some state based on that data.

There are just too many odd nuances and indirections with fetchers for me to want to use them.

defer

We might be encouraged to use the defer utility in the loader. The concept is pretty slick. It really let's you pull the lever up and down on the data you need right away vs a bit later. However, it comes with some rough edges as well.

If you're using typescript and were previously casting the loader data like this:

That's now broken. defer returns an instance of DeferredData but in your component, what gets returned is an object that contains promises. You end up having to add some more indirection:

Additionally, to use this promise you'll need to use the Await render prop component which, like fetchers, doesn't come with any onSuccess or onError callbacks to make use of.

The issues I've discussed here with defer and Await aren't unique to react router/SPA's but I thought worth mentioning.

Actions

With react router and Remix, we're told to "use the platform". This translates to using search params and FormData and leaning into uncontrolled form inputs so you don't have to manage form state and it supports progressively enhanced forms...if you're using Remix. Not so much with react router since there is no server component to handle form submissions.

Are progressively enhanced forms good? Absolutely...in certain contexts. When I'm using just react router to build a private internal app for ~50 users all located in a single major city, progressively enhanced forms are just not relevant. If you're building apps for millions of users that are all over the world being used by all sorts of devices, that's a different story. I have never worked on one of those applications. I fully understand that using just react router eliminates progressively enhanced forms. I don't want to be beholden to its implications in the apps I'm building. Thanks, but I'll opt out of the hard mode that is adhering to progressively enhanced form restrictions but not actually progressively enhanced.

So what's my beef with its "implications"? Just like fetcher to load data, you are forced to use "the platform"'s apis: URLSearchParams and FormData. This means you're encouraged again to go through an awkward layer but this time it's html and FormData. I realize this sounds kinda ludicrous. Html is awkward? Yes, using it as the source of truth is. Hear me out.

If we're going to use the recommended approach, a form component could like something like this:

Even though my form elements are mimicking different data types(string, boolean, number), FormData doesn't care. Everything you formData.get() out is a string. We're responsible for coalescing that back into the appropriate types for our api endpoint.

Also notice that since we're modeling our data in markup we have no type safety there. Hopefully you, or your editor, will catch typos such as the fact that the Favorite Number input's name is misspelled.

This gets even more awkward if you're modeling objects and arrays.

The "easiest" way I've found to do this is to use a special input naming syntax, employees[1][name], and then use a package like qs to parse it out from request.text(), not request.formData().