It’s been a while since I’ve written a technical post. I’ll do one now! I really do enjoy writing a few things. Even technical posts! Writing technical posts gives me the opportunity to go over something in my head to see how it makes sense. And if it possibly makes more sense! Or if I can discover anything else that I want to do with the current project that I am working on.

exercise

I believe exercise to be a wonderful thing for me, and certainly for about anyone else. For me at least, I know that I need regular exercise, because my career mostly involves sitting around all day long, and with some walking. If I don’t do regular exercise, then I know that my health will gradually decrease. For that reason, I have been weight training and running for a while now.

As I have been working out, I would come to think every now and then it would be great to have some sort of application to help with working out. As I thought about it some more, I would like an application to have a good list of exercises, including the ones that I am doing while in training.

And so I started to make some sort of a workout application. But this won’t be any regular workout application, This application will have a specific design to it in order to match one’s own skill level. I have a specific idea in my head, and I believe that idea could work. Maybe I’ll explain it later once the project gets to a usable spot!

where’s the technical stuff

This was one thing I learned recently. As I was developing the exercise application with react-scripts, react-dom-router, and @redux/toolkit as a single page application, I was finding that there could be a potential high amount of unnecessary network calls. All the network calls come from requesting static exercise data.

Those network calls were getting increasingly unnecessary because I would use the same network call to receive the exact same data I just got a couple minutes ago. It would be great if there wasn’t extraneous network calls. So I would have to some how store the data. But I really did not know how that could be done with react-scripts. So I just sat on it until an idea came to me.

And so an idea did come to me! I was reading in @redux/toolkit documentation at the configureStore method, and I saw the preloadedState option! I read a little bit more, and the preloadedState option could be used to set the initial state of the application from a previous state! Perfect! But how to store the previous state?

The answer quickly came. I remembered the onbeforeunload function. That fires right before the web browser actaully refreshes or closes a page (doc reference). So if I could capture the state and store it into localStorage then that would be a perfect solution I think! I’m not sure how that could go wrong. And storing the state of the application into localStorage seems to make sense. I could allow offline user exercise tracking with something like IndexDB later.

I first made the onbeforeunload event.

1
2
3
4
5
6

const store = configureStore(storeConfig);

window.addEventListener("beforeunload", (evt) => {
  const previousAppState = store.getState();
  localStorage[APP_LOCAL_STORAGE_KEY] = JSON.stringify(previousAppState);
});

I need this code to be in the same file where the redux store is initialized, so that I can call store.getState() method. Once I get the application state, I then stringify that state data and put it into localStorage. But how to I pull it back? Easy!

I’ll admit, I did first think to use the onload event, but that was going to be asynchronous and I could not get the state data in time to set the initial state. Then I realized I could just pull the data out of that onload event. Like so!

1
2
3
4
5
6
7
8
9

const parsedPreviousAppState =
  localStorage[APP_LOCAL_STORAGE_KEY] &&
  JSON.parse(localStorage[APP_LOCAL_STORAGE_KEY]);


const storeConfig = {
  reducer: { ... },
  preloadedState: parsedPreviousAppState,
};

I first check to see if the previous application state exists in localStorage, and if it does exist I pull it out and parse the JSON. Then I set that parsed previous state into the configuration object for the new state store. I tested out my application, and it answers the question of limiting unnecessary network calls! And the application does overwrite any stored data as it sees fit.

I do think that this could possibly not work if I need to update the exercise content. So I would need to integrate a service worker with version numbers. Hopefully with that, the web application could perform an “update” and give new exercise content.

beforeunload

I like how the data persistence is running in this application! I make sure I use localStorage to store the previous state data. Then when the application loads, I pull the previous state data if it exists and I set the previous state into the initial state. Easy and simple answer for data persistence and lowering the amount of unnecessary network calls!