IO.vue can be initialized before meta is received

jlsjonas commented 5 years ago

This is a bug.

Prerequisites

[x] Are you running the latest version?
[x] Are you reporting to the correct repository? (enso is made of many specialized packages: https://github.com/laravel-enso)
[x] Did you check the documentation?
[x] Did you perform a cursory search?

Description

IO.vue might get initialized before meta data is received from the server, causing Echo initialisation to fail (since this.meta.pusher.options is null)

Steps to Reproduce

load enso using HMR mode (seems to be 100% reproducible this way on my side)

Expected behavior

io.vue to wait for it's required options before instantiating Echo

Actual behavior

race condition

aocneanu commented 5 years ago

This shouldn't be possible.

Did you do anything to customize Home.vue ?

Because if not the watcher for appState won't allow entering the app, or changing the layout to Default.vue before the store is ready:

   watch: {
        appState(appState) {
            if (appState) {
                this.enterApp();
            }
        },
    },

jlsjonas commented 5 years ago

Did you do anything to customize Home.vue ?

Nope... I still see that part in CoreHome

Just went through the flow and I can clearly see it switching from the Home component to the Default component; consistently loading io.vue before appstate data is provided 🤔

(both in dev & hot mode)

aocneanu commented 5 years ago

So enterApp() is called before the appState being true?. Add some console logs and give me some more insights. I tested on my setup and everything seems ok.

jlsjonas commented 5 years ago

Trying to figure out why it's getting called as we speak; I'll report back soon

jlsjonas commented 5 years ago

Looks like enterApp() is being called after appState is set to true, but the actual app state isn't propagated (yet?). adding some watchers...

jlsjonas commented 5 years ago

Looks like there's a ~5sec propagation delay for some reason; no idea where I should look for it's origin though.

It does seem to be mostly limited to IO.vue though as I can visually see several other components using appstate data (i.e. menu, custom dashboard, ...)🤔

Also note that I don't have anything custom (yet) in store, IO.vue, ... currently patched codes: SideBar, AuthForm & Menus

The VueX debug tool also freezes up for the same pause after setUser, while initEcho seems to be triggered just before setUser commits to VueX

jlsjonas commented 5 years ago

Pinned it down further, but really at a loss now.

I have some custom code that overrides the meta data after an extra ajax-request. this is what triggers the debug watcher, and thus seems to actually populate the meta data towards IO.vue.

Without this extra update IO.vue remains unaware of state.meta actually containing data.

I'm leaning towards the race-condition theory again, where the new modular structure is still being initialised while IO.vue is already trying to initialise echo.

However, executing this.enterApp() in a this.$nextTick didn't fix it... 🤔

aocneanu commented 5 years ago

have some custom code that overrides the meta data after an extra ajax-request. this is what triggers the debug watcher, and thus seems to actually populate the meta data towards IO.vue.

I suppose this is causing the problem?

Why don't you use the localStore.js to modify the meta in the same inital request?

jlsjonas commented 5 years ago

Don't read between the lines 😋 The extra code is the only thing what's enabling me to get echo initialised through a watch workaround right now, I'm using localstore.js for it btw (it's a call to an external system that has to be made from the client)

aocneanu commented 5 years ago

Don't read between the lines 😋

I'm tired and old :D

In theory the state should not be instantiated until the localState action is done. Could you share the code?

jlsjonas commented 5 years ago

I'm tired and old :D

I disagree with the 2nd part :)

In theory the state should not be instantiated until the localState action is done. Could you share the code?

It's unrelated.

Even without any custom localstate code the io/notification echo isn't able to read the state's pusher options; not sure what the cause might be though

aocneanu commented 5 years ago

I really can’t replicate it

jlsjonas commented 5 years ago

I'll see if I can replicate it from a new enso project later this week

jlsjonas commented 5 years ago

I have no clue what made it work after the few-second delay (which led me on a completely wrong path)... but I feel stupid as to why it wasn't working as expected... 😬

🤦‍♂️

aocneanu commented 5 years ago

oh wow

enso-ui / ui