Document settings ignored when loading document as a script #269

Settings specified via macros at the beginning of a LiaScript document are ignored when that document is loaded via a script argument. They are respected when the document is loaded via a query string parameter. I've tested this specifically with the mode and dark macros, but reading the code I believe the problem will occur for anything in the model.settings structure. I've been investigating this in the context of SCORM 2004 output (and I believe it's the cause of LiaScript/LiaScript-Exporter#68), but I think it will be present any time the document is loaded through the script argument.

I've dug into it a bit, and I think I have a rough grasp of the problem. I'm not 100% confident I understand it, so I wouldn't be surprised if there's gaps or inaccuracies in what follows. But the problem seems to be a race condition between when Script.elm:init_script runs, loading settings from the document, and when Database.ts:Service.init runs, loading settings from the connector.

When the document is being loaded from a script, the init_script function in src/elm/Lia/Script.elm runs almost immediately on page load. The properly picks up the settings from the document. They are correctly passed to the view function of src/elm/View.elm. Some time later, the initEventSystem function runs, which calls Service.init in src/typescript/liascript/service/Database.ts. This triggers connector.initSettings(connector.getSettings(), ...). In the case of the SCORM 2004 connect, it attempts to load the settings from cmi.suspend_data, falling back to the default settings if these do no exist. (The base connector does similar, but tries to pull the stored values from localStorage.) After this point, the view function starts getting these settings. This means that the priority of settings is (stored settings) > (default settings) > (document settings). Since the default settings provide all possible values, the document settings will be ignored.

In contrast, when the document is loaded from a query parameter, the loading process presumably kicks off an async request for the document before continuing onwards. This means initEventSystem runs first, loading the stored values and falling back to the default settings [1]. Then when the request for the document is resolved, init_script runs, loading in settings from the document. This means that the document settings win. I think that the priority becomes (document settings > (default settings) > (stored settings), as the init_script uses the default settings for anything not specified in the document. But I haven't played with the saved settings much yet, so it might be (document settings) > (stored settings) > (default settings) [2].

A solution might be putting a pause in the script loading sequence, so that the event system initialization runs first. But I wonder if a better solution would be to wait until both the document and the connector have loaded, and then merge the three sources of settings (document, stored, and default) together once in the desired order. This would separate settings priority from the load sequence, hopefully making it easier to reason about.

I hope this makes some sense and is mostly correct. This is my first time poking around this code, so don't assume I know what I'm talking about. I happy to help with a solution, once we figure out what that should look like.

[1] I don't know that the path between the document request and initEventSystem is entirely synchronous. If it's not, there could be a race condition here, with different results depending on how quickly the document request is resolved.

[2] Neither of which is what I'd anticipate. I'd expect the order to be (stored settings) > (document settings) > (default settings).