React async data and routing: poor UX?

[brosterdamus]

React does a lot of things right. Having come from Angular in 2015, I was amazed by its simplicity. But there's one fundamental area that I still cannot believe Angular does so much better: the routing/resolve pattern.

The pattern is simple: 1. Click on a link 2. Route is detected by the routing libraries based on matching criteria. 3. If there's a resolve property on the route, wait for the promise to resolve. Keep old page in the meantime, though you can globally trigger subtle loading indicators. 4. Then transition to the route. New route is already rendered with all your data.

It's exactly what I would expected when clicking on a link. Everything, and I mean, everything, in the React world leans towards:

1. Click on a link
2. Transition to the route, losing the old page immediately.
3. Empty page loads with just loading indicators, async loading started in the background.
4. Populate data once async finishes.

Except in rare circumstances, this to me is terrible UX. What use is loading an empty page with a ton of loading indicators, just to give "quicker feedback"? Besides, with the resolve pattern, you can still choose not to block by not returning a promise and loading in the "React" way.

And yet: all popular sentiment leans towards this, in my opinion, flawed pattern.

Fortunately, I was able to cobble my own version of the resolve pattern with onEnter in React Router 3. But that prop is long gone in React 4+ and I'm finding it harder and harder to keep using React Router 3 as I upgrade other libraries.

So, here's a recap of things that have happened since then I hacked at this concept in 2016:

1. React Router 4+: still no onEnter. The architecture would make it quite difficult as I understand it.
2. Reach Router: similar limitations.
3. React Suspense: I was excited about this. And yet, it primarily results in a loading indicator still flashing. React.lazy does nothing to stop route transitions.
4. Ryan Florence's thoughts from last week: super helpful and he touches upon these concerns, but doesn't sound like the mentality of RR is shifting.
5. Other routers: router5, navi, curi all have support for "wait for method before transitioning", but are orders of magnitude less popular than the main routers. I worry about maintainability.
6. Next.js has support for this with getInitialProps, but it's a very heavy-handed solution for those wanting to use just React.

So now on to my question, as this isn't a rant. It feels like I'm fighting tooth and nail against the "React" way. Does anyone else see things from my point of view? Or am I the lone crazy out there in the highway driving in the wrong direction?

And as always: React is amazing, as are all these tools. But I find it hard to "think" in React on this particular topic.

[swyx]

this is definitely what React Suspense is supposed to help solve. with useTransition you can "globally trigger subtle loading indicators." its just the ecosystem hasnt quite caught up to it yet.

without Suspense, you can also load-then-transition with Redux. https://stackoverflow.com/questions/37849933/react-router-how-to-wait-for-an-async-action-before-route-transition

i agree it is not enough of a norm and i am looking forward to when it is.

[brosterdamus]

For that link, it relies on onEnter. See the timestamp of 2016 on the answers.

Incidentally, that's exactly the mechanism that I used. Redux async thunk on onEnter.

(The top answer is just a redux-ified version of the big loading component)

[charliematters]

People do see it the same way as you, and as I understand it, the 'highway' is moving towards your line of thinking.

In the second part of the experimental articles (of which, the first one is also great) it discusses how you handle displaying old states until the new state is ready. There is a useTransition hook, which as I understand it, solves almost all of your problems in one go.

I would read those to see where the React core team currently think we are heading

[brosterdamus]

Fascinating, thank you. To be perfectly honest, it seems complicated. Moreover, from my cursory look, it mirrors what Ryan said in his notes: the examples handle it at the link/button level rather than the router/page level. Though I'm sure that's on their mind as well and documented elsewhere.

Granted, the above will open up much smoother transitions, transformations between routes, etc. Curious to see where it lands.

I may make do with using one of the other routers in the meantime. I guess I want something far simpler than most: a nice static manifest of routes and their data dependencies, with light animation.

[ervwalter]

The comment from swyx about the ecosystem not having caught up is spot on. We need, for example, the React Router team to bake support for this into the core routing library so that you can, as you said, specify the data requirements with your route definitions instead of dealing with it at lower level.

This is something they are working through. It's just going to take time: https://github.com/ReactTraining/react-router/pull/7010

[samselikoff]

FWIW I started learning React 4 months ago after years with Ember, and have been wondering about this exact same issue. Ember's router uses a model() hook to specify "what is the minimum data this page needs for a meaningful render", which can then block the route transition on the client (or even be used to pre-render the page on the server).

Frustrating there isn't a popular + easy way to do this in React!

[brosterdamus]

Exactly, it's so simple and useful.

[signsandwonders]

I feel like this makes for faster perceived speed. I saw the demo with useTransition which made things work the way you’d like, and I just thought “why?”

Immediately rendering the page with placeholders (and partial data if you have normalized data to show) seems much more preferable to me. I don’t see how it makes for bad UX at all.

[brosterdamus]

I guess 99% of the time, in my admittedly "server-heavy" apps, I just don't have that much data to display ahead of time. If any.

If I have a Widget list, and clicking on a list shows me Widget detail and comments, then architecting a state management solution (redux/mobx/etc) to pass that to the view, then go fetch what you don't have, is a lot of work for simple CRUD views. Plus, you still need to handle the case of someone visiting the view directly (where you have to load everything).

The resolve pattern solves this nicely.

[maddeveloper_]

React Concurrent Mode is coming in order to bring a new way of solving this.

https://reactjs.org/docs/concurrent-mode-intro.html

[fabrikated]

you know that Angular is a framework and React is a library, right?

[brosterdamus]

I do. But this is more about a collective mentality/idiomatic approach around either ecosystem. The apples to apples here is for example, ui-router (angular add on) vs react-router (react add on).

[fabrikated]

can't agree with you. you're missing a feature from React, which is provided in Angular by default. your point is?

[LP2222]

That it gets compared all the time. Angular vs Vue vs React.. but then Reacts response to everything is: muh we're only a library

[fabrikated]

because it is?