The web has to be asynchroneous with fallback (to simplified content) and with error handling, but sometimes some (or a lot) of the operations have to be performed in a sequence. If some data is not yet loaded, but it is expected to be used (and this is “critical”), the process has to be attempted again when the data is loaded. As this might take half a second or several seconds, the things can get messy.
The mockup for dictate currently uses synchroneous load of the words from internal hardcoded function and afterwards the words can be splitted to sylables. So the logical approach is to create HTTP request to load the words (for example to local session storage) and after some time to attempt to process the words. If it completes- great, but if it fails, then it has to be attempted again after some time.
In such cases the seemingly useless splitting to separate functions is of big advantage- if something fails- it can be more easily restarted again.
The event driven approach is of course preferable, but not always it is known if the data is present and long waiting times, just to be sure that everything is loaded, have to be avoided.
So for the dictate mockup as example- some text is entered and is split and then it waits for user interactions. What happens if one (or more) words is not present? Can it be continued further? In some cases it might be acceptable to skip something, but in general it is not acceptable.
Loading hunderd of megabytes in advance just to be 100% sure that the words are ready to be used is not acceptable. Waiting 50 miliseconds (best case) for a word to be loaded via HTTP request from the SQL DB is ok for short texts, but if the text is longer than 10-20 words, then it becomes noticable. What if a word is missing in the DB- should the page freeze?
As the texts to process in the final version will be known in advance- it might be more feasable to process the text on the server and pass short dictionary as XML. With the squential loading of the HTML files, it is possible to load the text and dictionary first and afterwards the JS can process the text.
It is still to be decided, but the options are:
- load page and scripts and then load each word separately and at the end restart the scripts. Pro: debug at each step. Con: lot of loading, rechecking and error handling.
- load page and scripts and then load a bulk dictionary and at the end restart the scripts. Pro: single step for dictionary download. Con: page still has to be loaded and then the text reloaded. Simpler error handling.
- load the text and the dictionary while downloading the page. Pro: probably simpler. Con:debugging with predefined (on the server) text only.
Still have to decide which approach to choose for first attempt.
Looks like time for new POC (proof of concept).
As the DEV PC is different from the internet facing web server and I do not want to either install web server on the DEV PC nor install VS Code on the web server, the CORS has to be enabled. One of the simplest ways is via .htaccess by adding
Header always set Access-Control-Allow-Origin "http://devPCname"Whe selecting sequentially 100 words it do not take seconds, because the requests are currently served over h2 and they are concurently requested over same connection. The time to response is less than one second.
Selecting bulk of 20 words also does not significantly increase the time- 60-70ms for 20 vs 50-60 for single word.
Comma separated bulk version , single word per request version and bulk XML version
example words from the POC SQL DB:костилка,автомобил,къщата,одобрявам,парцалите,приспивате,ведро,готвя
The three approaches are feasible from performance point of view.
AJAX test is performed using this test page.
The easiest approach is probably to split the text to sentences and words, check if the words are in the downloaded dictionary and start download, split to sylables and letters and on error retry after a while with the new distionary. Error handling is try-catch and on error the process is restarted.