[andrewstuart]

My react applications cache nothing and don’t use global state except to put the user Id in localstorage.

No redux, no context, no network cache, no nothing.

Minimal props.

I just use custom events to tell the rest of the application what to.

And use fetch to get stuff.

Does away with all the complexity of state management or prop drilling.

[IceDane]

Not gonna lie: that sounds absolutely awful, and I can't imagine this works at any real scale. It will also have poor UX, because your users will be waiting for data which you already fetched and should just have cached.

There are also plenty of applications where what you are describing is arguably just not feasible at all, like heavier applications that due to their nature just need a lot of client-side state.

[hobofan]

If you have a fast API it's very feasible. I'll take slighly reduced UX due to slower page load times any day over unpredictable completely broken UX introduced by bad state management (common with e.g. Redux non-RTK in the hands of inexperienced frontend devs).

I'd personally still favor Next.js + TanStack Query if given the choice.

[edgyquant]

One of the apps I currently manage does this. It works fine, but that’s because we’ve basically reimplemented redux

[supermatt]

If you have multiple components that require access to the same data do you fetch the same data multiple times?

[andrewstuart]

I send it in a custom event to the part of the system that needs it.

Or I ask multiple times.

Asking multiple times is a tradeoff - if you are really needing to economise on back end server load then maybe front end caching matters more. But if your back end isn't going to mind, then ask again.

[bradfox2]

This is insane when react query is available and so easy to use.

[andrewstuart]

Custom events are insanely easy.