Closed siefkenj closed 2 years ago
I am not going to be over picky given that you are doing all the work and it is going in the right direction, but it would be nice to have more certainty about
domReady
- is the new version indeed correct, or it just happens to work on a particular nice computer which does things fast enough?
I wrapped all entry points that access the dom in a call to domReady
. I searched for a way to delay the loading of the dom in debugging mode, but I couldn't find any such thing. I believe the new version is correct, but coding can be hard...
We'll do the usual field testing then - release it to public servers and see if there are any complaints and reproducible errors, so we have something to debug.
The move of domReady
inside make()
creates a pretty big diff, but hopefully you like it!
This PR does two things:
window.sagecell
(and other globals) are set and read from exactly one place (in the start ofmain.js
). Asagecell.js
is now imported into files that used to rely onwindow.sagecell
being defined. This means the files can be moved around/globals can be renamed without affecting functionality.domReady
is now explicitly called when needed. It was previously loaded asdomReady!
which is a requirejs directive to tell requirejs not to execute the function untildomReady
has completed. There is no webpack version of this functionality. So,domReady
is not explicitly called where needed.For 2., I have tested the code, but the code also seems to work if
domReady
is excluded entirely. I would have expected it to fail, but I believe the asynchronous creation ofmakeSagecell
allows the time for the dom to be loaded.