Closed zeule closed 5 years ago
I believe this may be better handled via Tweego's --head
option, which you can access via the HEAD.html
file in this boilerplate, which adds elements to the document's <head>
and can be used to load scripts and styles. Or the SugarCube (if you're using that format) importScripts()
method which will add said scripts asynchronously and outside the engine's scope. Both of these options are great for loading web libraries or other code that shouldn't or can't be in the engine's scope. If the issue is an attempt to load a web library, there's an example of a wrapper you can use in the story JavaScript files to get most (9/10 or better in my experience) web libraries working. It looks like this:
(function (module, define, exports) {
// library code goes here
}).call(window);
I get the general wisdom of putting a <script>
element in the document body for a normal web page, but since the entire engine is loaded prior to dismissing the load screen, I don't see any advantage to adding a feature for this.
If the HEAD.html
or --head
option of Tweego don't serve your needs, let me know why and I can try to implement what you have there if it seems like a good idea.
To recap, the current options you may have are:
<script>
elements to the HEAD.html
file or use the --head
command-line option for Tweego. importScripts()
. Thanks for the reply and the suggestions. The --head
option does not help because it puts the script before the format script, and format API can't be used freely from the script. importScripts()
probably does what I need, somehow I overlooked that in the SugarCube docs, that seems to be simpler than patching the resulting HTML file. Thanks for pointing that out!
The head option comes after the engine but is out of scope. The importScripts()
method is also out of scope, so no format APIs.
You can't have both. There are no meaningful limitations on story JavaScript except that the code is automatically in strict mode (which may cause you problems if you aren't expecting it) and that most web libraries won't find the window
object and therefore need a wrapper to help get the context they expect.
What exactly are you trying to accomplish that you feel you can't do from inside Story JS?
(It may take me some time to get back to you with any further replies.)
The head option comes after the engine…
Pardon, don't understand that. SugarCube2 (SC2) code is placed within <body>
by tweego, how then any <head>
links can be processed after SC2?
The importScripts() method is also out of scope, so no format APIs.
I still can use the SugarCube
object, and that means I can access the story variables.
importScripts()
with await
call from the story init passage does the trick. I think this can be closed, unless you want to add options to concatenate and minify/transpile another dir with scripts, that will be placed near the resulting HTML file.
What exactly are you trying to accomplish that you feel you can't do from inside Story JS?
I want to avoid assigning to the window object in order to get global functions and variables, because long nested names in passages without auto-completion is unhandy.
The engine is loaded in the <head>
, including all SC APIs. The timing doesn't really matter, though, because you can wrap your <head>
code in a function that initializes everything and call it from story JS to get access to engine APIs via the SugarCube
debug object.
However, the SugarCube
debug APIs are not recommended for use by the author of SC, as they are not stable, so that is a house of cards. Generally if you want to interact with the engine, you want to be in the engine's scope. How much this actually winds up impacting your project is anyone's guess, but it's still worth knowing that those APIs are intended only for runtime debugging via the console, not really for building code on, but some people do so, so it's not like it won't work.
As far as not using the window
object, the setup
object is a thing, but that's more typing. I tend to adopt a "when in Rome" approach and try to use macros to manage most of my custom code, but macros aren't good for everything.
I have no particular plans to add anything, though, since I think this is a fairly specific use case and if you're happy enough with the results you have that's good enough for me, so I'll close this.
The engine is loaded in the
, including all SC APIs.
This is wrong (just tested).
I don't thinks the key attributes of the SugarCube
object (basically, the State
) will be removed while the State
object exists, and just using simple JS is much more comfortable than setup
, window
and so on... I think it worth the little risk of using the debug API.
Let me thank you once again for the help!
SugarCube executes scripts inside a closure (?) using
eval()
and that significantly limits what can be used in user .js files. To overcome those limitations, I patch tweego's output and inject<script>
tag there, which loads custom script: (sed -i 's/<\/body>/<script src="my_script.js"><\/script><\/body>/'
).I added a naive implementation to this template, but being a noob with node and gulp, I ask you to polish it and add mainline, please. It adds (see the diff below) gulp tasks for tweego invocation (creates an intemediate file), a task to replace
</body>
with<script>...</script></body>
in that file, and to rename the intermediate file. Also adds new directories to the configuration.