SugarCube executes s inside a closure (?) using eval()

The head option comes after the engine but is out of scope. The <code class="notransla

Please add an option to place user scripts in external file about tweego-setup HOT 6 CLOSED

zeule commented on August 10, 2024

Please add an option to place user scripts in external file

from tweego-setup.

Comments (6)

ChapelR commented on August 10, 2024

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:

Add the <script> elements to the HEAD.html file or use the --head command-line option for Tweego.
If using SugarCube, use importScripts().
If the issue is a web library that won't load because it's in the engine scope, you can use the wrapper mentioned above and in the readme.

from tweego-setup.

zeule commented on August 10, 2024

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!

from tweego-setup.

ChapelR commented on August 10, 2024

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.)

from tweego-setup.

zeule commented on August 10, 2024

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.

from tweego-setup.

ChapelR commented on August 10, 2024

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.

from tweego-setup.

zeule commented on August 10, 2024

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!

from tweego-setup.

Please add an option to place user scripts in external file about tweego-setup HOT 6 CLOSED

Comments (6)

Related Issues (14)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

Jobs