EnterApp() Lifecycle Error

[benloh]

Joshua reports:

Packaged builds: It turns out the packaged builds don’t work 100% and this causes problems for some students. If you go to this one I am hosting: http://www.joshuadanish.com/nc/Prok/#/ … what happens for me is that sometimes it loads just fine, and sometimes a blank white screen (what one student is indicating he sees on both versions). My console output is attached. If I load and it works, I find that if I hit reload I then get the error after a reload or two. But it’s quite consistent. I am assuming some sort of race condition and maybe on a students’ slower computer it happens more often, though when I tried adding network lag and latency via chrome it didn’t make it any more frequent. So … no clue.

[benloh]

Ben suggests:

3. Packaged builds -- This one is weird. And there might be multiple things going on.
   re http://www.joshuadanish.com/nc/Prok/#/ -- Yep I can see the problem. But there's a couple of weird things.
   i). It loads really slowly. This is a DO server?
   ii). The "SourceMap" warnings are due to my turning off sourcemaps in brunch in order to save about 1MB of data. You ought to be able to ignore those warnings.
   iii). I think I had forgotten to tell you to run npm ci on the pull request. I added a few new packages for cloning and compression. This server is definitely not running compression.
   iv). What kind of web server is handling this? Apache?
   I'll see if I can reproduce this problem. In the meantime, if you don't mind leaving that server up it'd be helpful.

[benloh]

Kalani responds:

No, this is running from Joshua’s personal web site. I’ve got one at https://dighist.indiana.edu/netcreate/#/ that’s running on IU’s servers, which the students will hit. Bandwidth concerns have us not running on DO, so hopefully IU’s servers are faster?

Yes, it’s Apache on the joshuadanish server. Pretty sure the Indiana.edu server is also Apache.

[benloh]

Joshua responds:

I just ran nom ci and re-packaged and put that on my server under http://www.joshuadanish.com/nc/Prok3/#/ (note the 3)

I am not sure I see a difference.

[benloh]

Joshua responds:

Newest version is now running at: http://142.93.63.36/graph/H213FA2020Prokopios/#/ (the other URL is live for students so this is safer).

I can’t tell if it is faster or not?

This does not appear to have the same problem - we only see it in standalone mode, though the student who it impacted said they saw something similar in the main app (that’s why we packaged). However, we have no error console from them and little else so … are not sure what gives.

If you want to compare to a smaller network, here is one also on DO that loads much faster: http://134.209.73.52/graph/CHAT/#/

[benloh]

@jdanish The new http://142.93.63.36/graph/H213FA2020Prokopios/#/ does work for me. And it clearly has compression on. If you go to devtools and look at the Network panel, netc-lib.js is only 1.2MB. Uncompressed it's 5.6 - 6.4MB.

If you need it to run standalone, you might try again with a standalone build.

http://www.joshuadanish.com/nc/Prok3/#/ is clearly not compressed -- netc-lib is 5.6MB

[benloh]

That said, there probably is a lifecycle sequence error that we need to deal with. Sri notes:

From what I can tell from the error, it's being thrown by client-lifecycle on line 152 of my current build. I should pull your most recent.

it is happening specifically during LOADASSETS, so I would check all LOADASSETS hooks. If this is running in STANDALONE mode then maybe that'a a factor.

It looks like only one place hooks it in nc-logic.js

window localStorage may not have been set

Originally when I wrote this code, I think I assumed that standalone mode would just preserve data.

If you are running a standalone fresh, maybe window.localStorage doesn't exist.

if you run the app once in network mode then local storage is already initialized, so that's why its intermittent

@benloh I just tried again and when I run it locally, the size is 1.2 or so, and then when I run package the version in the public folder is 5-6 MB again. Is it possible that when packaging it is not compressing? I am pretty sure I am doing all of the steps correctly ...

[benloh]

@jdanish Ah right. Compression is being done by the Node Express server as it serves the files. However, the Express server only serves the files with npm run dev or npm run classroom.

If you're running standalone/packaged mode, then Apache is doing your serving. If you want compression there, you'll need to configure your apache server to gzip the files.

Sorry 'bout that. I never use standalone and forgot how it worked.

Do you really need to run this standalone? Is there something else about the nature of the graph/class that requires it?

Well, we have been using it in two cases:

1. In the past, students who couldn't use the network for some reason including spotty internet used the standalone version to be able to see it without editing.
2. That's what we put on the website after the class is done for demos.

Obviously, 2 is less important. But 1 was the reason we were messing around with it this time.

[benloh]

Got it.

We'll address the error.

How urgent is this? When do you need it?

In the meantime, you might look into gzip on Apache.

[benloh]

@jdanish This should now be fixed with 6a6a2f7. Just pull the latest commits on net-debug.

[benloh]

The issue was that in standalone mode, the template (p2) was sometimes being loaded before the database itself was loaded (p1). Wrapping the whole call in an asynch allows us to manage the load order. See nc-logic.js lines 180 - 198.

[jdanish]

Confirmed this works for me / us. Now to see if it works for the student! Fingers crossed (though that'd be a different issue if it doesn't).