mst-gql
mst-gql copied to clipboard
mobxjs
mst-gql check if the store ready after rehydration
The frequent task is to render App when the store is ready and rehydrated but the problem is that I can find out when the store is ready but I can't find out when localStorageMixin finish work and the store is ready, for example, to check if a user is logged in to push him to match screen.
I see only two ways, one way I don't like is to make delay and another way is to create custom localStorageMixin that in the end change the property of model "ready" to true.
Would be great to have something like this resolved without the patch. I don't know how other but I meet this problem every project.
If you have a better way to resolve this issue so please let me know.
@chrisdrackett @dpnolte @elie222 @zenflow @RXminuS @rdewolff it is really needed feature
While I agree that it is not nice to mention everyone on your mind if you don't get a response immediately, I guess it is also a sign that there is not too much going on with mst-gql lately. It seems practically dead: no new releases, no answers to issues, no discussion, and a PR (#346) pending for weeks. How do you see the status of the project @jesse-savary?
If you have a better way to resolve this issue so please let me know.
I am using https://www.npmjs.com/package/mst-persist which returns a promise resolved after rehydrating the store.
@smokku Just curious..how is the performance with mst-persist since there is no throttling. It would seem like persisting to the store on every onSnapshot call would be a serious performance hit on your Rootstore.
Just curious what you were experiencing on that front.
I am whitelisting a small subset of store, so this is not an issue for me.
BTW, I am not sure how such throttling could work without potential for data loss.
Agreed, ultimately is there any point to whitelisting anything other then the calls themselves (__queryCache), which is the first thing I'm going to try.
I'm still going to implement a purging strategy tied to app versions so that I can fix issues if Im caching bad data.
Quick Update:
I could not figure out a purging strategy that works. Ultimately you want to load results from net http calls (aka the queryCache), but I found if i rehydrate only that, I get other errors which is really strange. If I store the whole thing, then the initial call to update the snapshot can take 1.5 to 2 seconds which is too long on app bootup.
Anyways...not sure if this juice is worth the squeeze but would be curious to hear how others did it and if it actually makes a noticeable impact on your app.
Will see if I can come up with something as AFAIK we encountered this issue with our app.
@Raserad in the future try pinging me :)
