API: initial app state gets initialized first then overwritten by cached script state #396
Labels
Comments
e18r
added a commit
to AutarkLabs/open-enterprise
that referenced
this issue
Oct 30, 2019
When you're working with an app and you refresh the browser, the app shows as loading, then the content loads, then you see an empty card, and then you see the content again. In order to solve this issue, let's dig into the three ways in which an app is loaded: A. On first load 1. The app state reducer is called with a `null` state (you see an empty card) 2. The store is initialized (you see an empty card) 3. The app state reducer is called with a state loaded from the store (you see the actual content) B. Coming back from another application 1. The app state reducer is called with the cached previous state (you see the old content) 2. The app statee reducer is called with a state loaded from the store (you see the actual content) C. After refreshing the browser 1. The app state reducer is called with a `null` state (you see an empty card) 2. The app state reducer is called with the cached previous state (you see the old content) 3. The store is initialized (you see an empty card) 4. The app state reducer is called with a state loaded from the store (you see the actual content) The issue at hand is caused by step C.3, which shouldn't take place, since the store is already initialized. I believe C.3 to be a bug from AragonAPI, which @Schwartz10 already [reported](aragon/aragon.js#396). A downstream fix for this bug can only take place in the app state reducer, since it is called before the store. We need a way to detect that step C.3 is taking place and refrain from updating the state before it finishes loading, since the old state that we already have is more complete. But how to detect C.3 based solely on the state? Sure, you can detect that the store is being initialized, but how can you know that it's not loading for the first time? What I came up with was to store the previous state that the app state reducer received, and compare it to the current one. C.3 is the only case in which the previous state has elements that the current state doesn't. If C.3 is happening, don't update the state; just use the previous one. And as soon as the current state is at least as complete as the previous one, update it.
sohkai
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When an aragon application loads, the first data to propagate (in my experience) is the frontend application state. The frontend application state is initialized from the previous application state - frequently this means the
syncedapp status is still cached as well as the latest block information.This poses two problem for frontends:
SYNC_STATUS_SYNCINGevent gets fired in the script.js file.As a result of these two problems, applications can flicker with information from recent blocks, THEN show syncing signs, and then show the right information. Here's an example from the voting app:
One solution is to reset the frontend application state on every session. The default
syncingparam could be set to false and avoid flickering UI. Also, the frontend application state wouldn't have information that the cached store doesn't keep. This would also save developers from some cached state confusions too.The text was updated successfully, but these errors were encountered: