Skip to content

Instantly share code, notes, and snippets.

@ryanflorence
Last active September 18, 2024 17:20
Show Gist options
  • Save ryanflorence/e8704973c05aeb56d18b368b26fe79fb to your computer and use it in GitHub Desktop.
Save ryanflorence/e8704973c05aeb56d18b368b26fe79fb to your computer and use it in GitHub Desktop.
Feedback for José

Article Feedback

Shared Links UI

I decided to give it a try, find some bugs, and discuss possible root causes.

This UI doesn't use Remix's built-in conventions, it uses React Query talking to a backend API like many React SPAs.

The behavior shown in this video is not the behavior of Remix: https://x.com/josevalim/status/1832509464240374127

Given the following sequence of events described in the tweet:

  1. (client) request to delete link1 sent
  2. (client) request to delete link2 sent
  3. (server) deletes link1 and loads a new list (includes link2)
  4. (server) deletes link2 and loads a new list (no link1 or link2)
  5. (client) receives link2 response
  6. (client) receives link1 response

Remix would have thrown away the revalidation for (6) when the revalidation for (5) landed because (6) is now stale.

It would work like this:

submission 1: |----✓---R------------❌
submission 2:    |--------✓---R-----✅

The rest of the jankiness in that UI is easily handled by Remix APIs, so remember that UI is using React Query, not Remix.

Two Round Trips for Mutations

This is a default behavior, but you can avoid this if you want by opting out of revalidation with shouldRevalidate and returning action data to render for a single round trip mutation

Hello Database Revalidation diagram

From the article, this is inaccurate:

submission 1: |----✓---------------R----✅
submission 2:    |-----✓--R----------------✅
submission 3:              |-----✓------R-----✅

The actual behavior would be:

submission 1: |----✓---------------R----✅
submission 2:    |-----✓--R-------------❌
submission 3:              |-----✓------R-----✅

Submission 2's revalidation would be thrown out because the revalidation for submission 1 started later, so it likely has more correct data, and unlikely to show incorrect values as incorrectly stated in the article.

Because of this, the rest of the section is a strawman. It's describing typical bugs in SPAs that Remix fixes automatically.

Single Fetch Mutations

Given the context of the article, this section reads as if its still criticism of Remix behavior, when Remix doesn't have these behaviors.

It would be nice to see at the top that you're not explaining any of Remix's behavior here, but rather proposed solutions to this problem from others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment