This repository has been archived by the owner on Oct 25, 2023. It is now read-only.
reorg account init in truthsayer to make usage deterministic #419
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Current way authentication is handled in truthsayer: most UI components that require authentication are rendered conditionally under
PrivateRoute
&PublicRoute
which only show them ifMzdGlobal.account
is not null. Since historicallyStorageApi
was an always-ready singleton that didn't require init, this lead to code that treatsaccount != null
checks as "application is fully ready".This became problematic with the addition of extra things which have asynchronous initialisation to
MzdGlobal
, likeMzdGlobal.storage
which has to fetchAppSettings
from archaeologist before it can correctly initialise itself. Components start rendering as soon as authentication is done and they start using other parts ofMzdGlobal
which may or may not be ready. At best this leads to a brief moment whenSearchGrid
starts to furiously load nodes from our datacenter, even if user chose to use offline mode. At worst it can lead to unexpected access toAlwaysThrowingStorageApi
which crashes the whole UI.Hacking around that turned out to be awkward and fragile, so this PR takes a different approach -- it changes the role of
MzdGlobal
in a three ways:MzdGlobal
now only exists when a user is authenticated and it's only accessible to components under private routesMzdGlobal
renders its children only once it's fully initialised (including async init) which enables its deterministic usage without surprises.MzdGlobal
which allows to render public routes withoutMzdGlobal
existing at all#351