10 ms·
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.
by andrewstuart 3y ago
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.
- supermatt 3y agoIf you have multiple components that require access to the same data do you fetch the same data multiple times?
- andrewstuart 3y agoI 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.
- IceDane 3y agoNot 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.
- edgyquant 3y agoOne of the apps I currently manage does this. It works fine, but that’s because we’ve basically reimplemented redux
- hobofan 3y agoIf 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.
- bradfox2 3y agoThis is insane when react query is available and so easy to use.
- andrewstuart 3y agoCustom events are insanely easy.