Make useStorage hooks more reliable (probably)

[emlun]

We've seen problems with the login procedure sometimes failing to set privateData in local storage. This seems to be because the internal useState hook sometimes fails to update currentValue even though setValue() was called. This made the internal useEffect hook fail to write the new value into local storage, and also made the new state fail to propagate to other instances of the useStorage hook.

I don't know why this happens, but these changes refactor the data flow such that the public setter function always writes to local (or session) storage and then notifies other useStorage instances with the same name. This seems to make the login procedure reliably set privateData successfully.

I have seen some issues with this too, namely that the login procedure would hang on the eDiplomas spinner and not move on to the logged-in view. However, this only happened when I had some console.log statememts throughout the hooks for debugging. I have not seen the issue without these console.log statements, so I hope this is fine? Anyway, just so you know in case that issue returns.

[gkatrakazas]

Great! Look like it's working, we are testing it a bit more and we will merge it.

[emlun]

I've been digging more into the issue of hanging on the spinner, and it seems I can still reproduce it fairly reliably by

1. Log out
2. Press Ctrl+Shift+R to force-reload the page
3. Log in

This still results in hanging on the spinner fairly often. But I think this might have to do with other state management throughout the app. 🙂 I've noticed that handleServerMessagesGuard tends to open multiple sockets and sometimes fails to initialize, which results in hanging on the spinner. But after I restructured that code to be more reliable using hooks, the app would instead still show the login form even after successful login (reloading the page shows the logged-in view though, indicating it's a frontend state issue). I can't tell what causes this - <Api>, <Login> and <Notification> both re-render, but neither <PrivateRoute> nor <Home> ever even attempts to render. In fact it seems like the router still has /login as the current location even after <Login> calls navigate('/'). 😕

[gkatrakazas]

I believe the spinner issue might be resolved with this commit: gunet@ffd6535

[emlun]

Cool!