Refactor quiz page load JS

Created by: iainbryson

In investigating the (now theoretical) issue #112 (closed) I went down a path of sanitizing the page load procedure for quizzes and got the code mostly complete. There were several concurrent processes run at once which didn’t coordinate. And while it doesn’t seem to have caused problems now, it definitely can be improved.

~ Nice. That is a great improvement! =)

So I did a small refactor of it before you discovered there was no problem, but I think this refactoring is worth considering. And if so, we should decide what UI if any it has.

Here’s the design:

For a page to show a quiz, 3 things are needed: (1) the page must be rendered — including MathJAX (2) the web sockets connections must be established (3) the page must be full screen

(2) and (3) are of course is only required if a student is taking a quiz, and (3) only if the quiz requires full screen.

Previously, each of these processes were being launched separately — render the page, ask the user for fullscreen and connect to the server with web sockets. The refactor creates an overseeing object which contains the state of all three. Using this, it can show or blank the quiz until each of them are ready at load time and if any of them stop being true, blank the quiz. It also would allow us to show a loading message (e.g. loading…, establishing connection…) if we wanted to.

Previously with MathJAX, we’d just call the API and expect rendering to eventually finish (this leads to weird changes in the equations you may have noticed).

We can prevent all that and not begin the quiz until everything is in place. This should ensure that when a student sees the quiz, it’s ready to go: it looks right and it’s connected.

So, if that sounds good I’ll finish up that work and commit it. And also, I’d need to know if you like the idea of a banner notification on the blank screen going from “Loading..” to “Rendering…” to showing the quiz. I can remove this and just show the blank screen which we render/get connected/request fullscreen.

I hope this makes sense!

~ Very interesting read!!

~ Yes, let's give some feedback to the user while each stage is processing. This makes the wait feel shorter and maybe useful for debugging later on.

~ Great that you looked into it =)