0

I have a React/Redux application for my front-end, and a REST API for the backend and I use JWT as a sort of 'session' id (comes out of the box with Laravel Passport, my oAuth server).

Anyways, I was wondering what the best strategy is for hydrating the redux store when the page initially loads when you have a RESTful service that has endpoints for individual resources.

At the moment I'm doing it on component mount. So say a component lists a resource, I call the api/hydrate the store on component mount for that resource. This results in many API calls though, and it can result in unnecessary calls when the component mounts again.

Is there a better alternative to this that you're aware of? My main concern is that I don't want to introduce some weird endpoints to my API specifically for hydrating pages.

Carwyn Stephen
  • 134
  • 4
  • 23

1 Answers1

0

Don't tie components to api endpoints. Use their lifecycle hooks to trigger the initial fetching of data, but by dispatching async actions. When a component is mounted again, it can render its resource from the redux state, or run some logic to determine that it's outdated and dispatch another action to update the store.

timotgl
  • 2,865
  • 1
  • 9
  • 19
  • I'm using the componentDidMount lifecycle hook to execute an async action I pass into it at the moment. Are you suggesting I use a different hook to only fetch the data if it's not present in the store yet? Like componentWillReceiveProps or something? – Carwyn Stephen Mar 21 '18 at 09:23
  • No I'd say you can do that there. Only dispatch the async action if the data is still missing in the props so the component can be re-mounted without triggering a request. – timotgl Mar 21 '18 at 11:08
  • Fair enough. Would you say that the extra HTTP requests from using this method is worth it for having a better designed API that I can consume from my own application as well as exposing it via oAuth in the future? – Carwyn Stephen Mar 21 '18 at 11:58
  • Do you mean the extra HTTP requests you would be saving or the ones you'd make over and over again when done on mount? Can't really judge your API design without knowing the app. All I can tell you is that when components are re-mounted quickly it gets really annoying for the user to wait for data to be fetched every time, you're basically losing out on one of the main selling points of single page apps. – timotgl Mar 21 '18 at 20:23
  • I was more talking about the multiple HTTP requests needed to hydrate an app over having a single request that gets everything you need. The multiple requests are great for keeping the API design clean, but performance wise it's lacking :/ – Carwyn Stephen Mar 22 '18 at 09:04
  • You could bootstrap the app's HTML, as it is served with the first request, with all this data, and use that as preloadedState when creating the store for the first time during runtime. Depends on your infrastructure. With effective caching this speeds up perceived performance significantly. – timotgl Mar 22 '18 at 09:30
  • Yea I've had a look at server side rendering, I guess I really want to interact with my backend only through the API, so that I can build the API I will eventually expose to the public at the same time that I'm building my app. Anyways I think you've answered my main concerns/made me feel better about my approach, so I'll leave you alone now :P – Carwyn Stephen Mar 22 '18 at 10:27
  • Hah no worries. Full-blown server-side rendering is a beast of its own, but only injecting some JSON data into the HTML is a quick win. If the server is the same that's powering the API you can even avoid going through the web layer and get the data straight from the source. – timotgl Mar 22 '18 at 10:48