Data Fetching for Single-Page Apps (martinfowler.com)

I would expect a bit more in-depth article from Martin Fowler website.

The shown implementation is naive and prone to bugs, for example a race condition. If this id is rapidly changed (say from 1->2), and the first request arrives last, you think you are looking at user 2 but you've loaded data for user 1.

const [user, setUser] = useState<User | undefined>();

  useEffect(() => {
    const fetchUser = async () => {
      const response = await fetch(`/api/users/${id}`);
      const jsonData = await response.json();
      setUser(jsonData);
    };

    fetchUser();
  }, [id]);

If you don't know what you're doing, use Tanstack Query libs or read a better article.

- https://tanstack.com/query/latest

- https://maxrozen.com/race-conditions-fetching-data-react-wit...

The missing syntax highlighting (or the absence of any highlighting) makes it really hard to read.

Plus the article only refers to React, but it could have stayed a bit more abstract about the techniques.

I know that Martin Fowler is your God, and that my denigrations upon this divinity will not go unpunished, or that this guy is not Martin Fowler, but what has this guy ever build to convince me that he actually knows what he is talking about? Maybe I am missing that or something else, but here I read that "Today most applications can send hundreds of requests for a single page", like one would hope there to be a sort of role within the software enterprise that would actively try to discourage people from being stupid like that.

Hey, at least when DHH jumps on the third rail of the hypermedia bandwagon I can laugh about the 500ms delay of a dropdown to show a calendar in his mail app, and I respect him for that.

I am horrified. I didn't see mentioned, proper data fetching _must_ happen before UI rendering if you want to have consistent behavior with classic HTML/HTTP apps, e.g. the current page content stays displayed until the received html starts to be rendered (with the actual data for pure HTML). You loading feed back _has_ to happen from the interacted page in first intent.

If you want to have an after routing/rendering loading feedback, such as skeleton or so, you still can do it, but it will be opt-in, not an after thought of savage data fetching and rendering that really might happens as the application gains features and diverts from the simple POC patterns.

Proper data fetching and rendering cannot happen without a router. Remix solved this with their updated react-router, I know that this router has a bad rep with breaking changes, but they finally landed the implementation that neatly cover most if not all the use cases for routing with dynamic code imports and data fetching.

The how is of course extremely simple. But when is the real question. You can do a full send on every route load, but at that point you might as well just do SSR. Dealing with stale data is a nightmare, but you want to have at least some client side inter-page caching to avoid redundant API calls. I've never found a perfect solution here.

The most common mistake I see is putting data fetching in the view layer.

React hooks caused this because by default there’s no sensible place to fetch data.

So unless you know ahead of time, any complex single page ends up with complex and hard to track network requests.

The solution is really simple: pull data out of the view layer and make it a first class citizen.

—

An exercise: imagine you’re building a tui instead of a web app, but you’re forced to use the exact same code for app state and data fetching… what would that code look like?

  1. This goes against the idea of fetching data close to where it's used, basically promoting modularization.
  2. From the POV of the children, you have to backtrack where their data are coming from.
  3. If components always use the same data, you have to duplicate fetching their data everywhere you want to use them.
  4. You can't partially show children, but have to wait for everyone to have their data before rendering them.

The article sort of touches on this, but in my experience working with React the most important thing is to keep as much as you can declarative. When you start doing things in an imperative way, particularly when they are async, that's when you run into problems. It's one of the reasons I find GraphQL such a good fit.

Bleugh. Who is this article for? (good bait from the poster) Anyone who's done any kind of meaningful SPA dev knows this pattern does not scale & for newbies, this is poison.

Instead of talking high-level framework agnostic code design and the multitudes of ways to fetch data (route based, state stores, authentication hooks, subscriptions, model composition , to name a few ); author goes deep into outdated React anti-patterns.

Everyone who has commented on this is spot on.

Should have "in react" in the title

I think it's fascinating how data fetching has been a mostly solved problem in Meteor for years.

I understand why you'd use Tanstack Query or similar solutions most of the time. I wish the mental overhead of using them was smaller.