What is the fastest way to reference an external function? Will it affect the speed?

[dublove]

I want to put some common functions in the same js for other scripts to call, is it necessary and will it affect the speed of the script?
What is the best way to reference external functions?
I see some people say //@include is better than #include is it?

[m1b · Accepted solution]

@dublove creating a "library" of functions is a great idea for your own scripts. It makes it much easier to maintain the functions—if you make an improvement to a function you just change it in that one library file, not every script that you ever put it into. However, if you make a change that breaks existing scripts, for example by changing input parameters or output values the scripts that include it will fail.

The *best* way to include a library of functions will depend on many factors, but I think in your case the best way is a simple

//@include 'path/to/script.js'

Note that #include 'path/to/script.js' is exactly the same as //@include—use whichever you like. If you use VSCode, then use //@include so it doesn't show a linting error.

The //@include 'path/to/script.js' line means that the entire code of script.js will be evaluated exactly as if it had been pasted in to your current script where that line is. This is the simplest way.

There are many other ways, and all solve specific problems, but all introduce issues too. I think keep it simple for now.

- Mark

P.S. just for interest, this is from a job I am working on now:

//@include '../Lib/IllustratorPackingAdapter.js'
//@include '../Lib/PackItems.js'
//@include '../Lib/TrentiumsPacker.js'
//@include '../Lib/Block.js'
//@include '../Lib/Bin.js'
//@include '../Lib/BinPacking.js'
//@include '../Lib/PackingAttempt.js'
//@include '../Lib/BinarySearchRange.js'

 Some of these "external" scripts are not very big, but I like to keep them separate. You can include as many as you need.

[dublove]

Learned, thank you very much.
Mine is only 10 functions or less.
They are very small, so I wrote them all in one js to save time.
I also just learned about value conduction in functions, something I never understood before.

Not easy, another step forward.

[m1b]

Excellent! Every step forward is a win!

By the way, here is a good tutorial on Javascript ES3 which is almost identical to ExtendScript. It is in English, but I hope you can make sense of it.

[dublove]

Thanks for sharing.
Just know that js is mainly used on web pages.
If it is used in ID scripts, I am afraid there is no money in it.
Time waits for no one. If I were 20 years younger, I would have had a great future if I was at the level I am today.
I'm not sure if I'd be 20 years younger, but I'm sure I'd have a great future.

Time is so relentless.

Sigh:
Time is unforgiving and people are loving.

[dublove]

@m1b  @Manan Joshi 

My Public Library "PubLib" is in the same directory as my Main Script "myScript".
PubLib.jsx need to calls mystyle.json, how do I indicate its relative path?

Here
... /PubLib/mystyle.json
should not work.

The scrip_folder seems to lose its meaning at this point?

PubLib.jsx lost its reference path.

Example Zip File here

[m1b]

@dublove you have discovered one of the annoying problems with the `include` approach.

The `include` is a pre-processor directive which means it isn't evaluated in the code itself. That's why you can't do this:

if (x===5) {
    //@include 'myLibrary.js'
}

The `include` directive is evaluated before the code is run and, in fact, is replaced by the actual code from the included file. This is important to understand.

Unfortunately this means that if you do:

$.fileName

in the included file it won't return the included file's path; instead it will return the top level script's path. This makes sense if you remember that the include directive is actually replaced by the code from the included file. EDIT: I'm not sure about this now, sometimes it works. I really don't understand this so ignore my comment and we'll wait for someone who is expert on this topic.

One simple solution is to only put only general functions into your library file. So instead of:

function myJson() {
    var script_folder = script_dir();
    var jsonFile = File(script_folder + " /mystyle.json");
    function script_dir() {
        try {
            return File(app.activeScript).path;
        } catch (e) {
            return File(e.fileName).path;
        }
    }
    jsonFile.open('r');
    var content = jsonFile.read();
    jsonFile.close();
    contentObj = JSON.eval(content);
}

Make you functions general, like this:

function readFile(path) {
    var file = File(path);
    if (!file.exists)
        return;
    file.open('r');
    var content = file.read();
    file.close();
    return content;
};

function evalJSON(path) {
    var json = readFile(path);
    if (!json)
        return;
    try {
        return eval(json);
    }
    catch (e) {
        return String(e);
    }
};

And then in your top level script do:

var myJSONObject = evalJSON(File($.fileName).parent + '/mystyle.json');
if (!myJSONObject)
    alert('Failed to load JSON.');

Does it make sense?

- Mark

P.S. the other approach is to hard code the script path, ie. use a complete absolute path, not a relative path. That will work anywhere.

Edit 2025-06-20: fixed ridiculous typo in the code example—sorry!

[dublove]

Hi @m1b 

That doesn't seem right.
Failed to load JSON.
What is the path that this code gets?
I'd like to directly replace the "script_folder" part of
var jsonFile = File(script_folder + " /mystyle.json");
, would that be more straightforward?

[m1b]

Sorry I made a mistake and edited my post.

It should be something like:

var myJSONObject = evalJSON(File($.fileName).parent + '/mystyle.json')

This gets the folder that the top level script is in, and adds "/mystyle.json" so the path points to a file "mystyle.json" in the same folder as the top level script.

If you want to look in your library folder according to your zip file: 

var myJSONObject = evalJSON(File($.fileName).parent.parent + '/PubLib/mystyle.json')

So my top level script could look like this:

//@include '../PubLib/lib.js'
//@include '../PubLib/json.jsx'
(function () {

    var myJSONObject = evalJSON(File($.fileName).parent.parent + '/PubLib/mystyle.json');
    
    if (!myJSONObject)
        alert('Failed to load JSON.');

})();

Hope that makes sense.

- Mark

[dublove]

@m1b 

I removed the VAR in:

var myJSONObject = evalJSON(File($.fileName).parent.parent + '/PubLib/mystyle.json');

and it worked fine.

I'm trying to see if I can add it to fuction.jsx

[m1b]

If you removed var then you are creating a global variable. If it didn't work without making the variable global then something you are trying to reach is out of scope. The structure of your file might need adjusting so everything you need is accessible without making global variables (which is a bad habit).

[dublove]

Yeah, couldn't find a good way to do it, and this is a good way to do it.

If I don't remove the var, I get a popup: json undefined.

I don't know how to pass variables across functions yet.

Thank you very much.
Right now my public.jsx looks like this

//获取Json文件
function getJson() {
    myJSONObject = evalJSON(File($.fileName).parent.parent + '/PubLib/mystyle.json');

    //if (!myJSONObject)
    //    alert('Failed to load JSON.');
   // if (myJSONObject)
      //  alert(myJSONObject);
}

function readFile(path) {
    var file = File(path);
    if (!file.exists)
        return;
    file.open('r');
    var content = file.read();
    file.close();
    return content;
};

function evalJSON(path) {
    json = readFile(path);
    if (!json)
        return;
    return JSON.eval(json);
};

[dublove]

myJSONObject = evalJSON(File($.fileName).parent.parent + '/PubLib/mystyle.json');

 Hi @m1b 

What is the JSON path? Isn't this it?

myJSONOPath= File($.fileName).parent.parent + '/PubLib/mystyle.json';

[m1b]

@dublove yes I should have written it like this:

var myJSONPath = File($.fileName).parent.parent + '/PubLib/mystyle.json';
var myJSONObject = evalJSON(myJSONPath);

[rob day]

Hi Mark,

I don’t do a lot of work with JSON, but just to clarify, when we read a JSON file it loads as a string—there are no built in JSON methods and objects (like there is for XML). So your readFile() function could be loaded from an external library, or be included in the script. In either case there needs to be another function to parse the string into something usable right?

[m1b]

Hi Rob, that example was just a rearrangement of what dublove had in their provided sample. I was suggesting making the library functions more general so I split the readFile from the evalJSON.

> just to clarify, when we read a JSON file it loads as a string—there are no built in JSON methods and objects (like there is for XML)

Remember that JSON is just specially formatted javascript object notation, so valid JSON will evaluate as valid javascript. Therefore, unlike XML, "JSON methods" are just normal javascript methods. Example:

// I think adding parentheses around the json string is a good practice
var data = eval('(' + readFile(pathToJSONfile) + ')');

if (data)
    alert(data.pdfName);

This is assuming that the JSON is from a trusted source! If not, then we should use the json2 library or similar.

> there needs to be another function to parse the string into something usable right?

Yes: eval(str) as in the example above, or JSON.parse(str)

- Mark

[rob day]

Yes: eval(str) as in the example above, or JSON.parse(str)

Must be doing something wrong—the evalJSON function is throwing this error:

The test.json

[m1b]

Oops, sorry @rob day its a very messy set up and I should have cleaned it up properly and you have just noticed my typos—of course the one time I didn't test because I was on my phone, grrr. I will edit the code above. (Sorry @dublove I really messed up this one, please look at revised code.)

- Mark

[rob day]

Will it affect the speed?

Hi @dublove , If you are loading external libraries thinking it will improve a script’s performance, I don’t think that is the case. The advantage of libraries would be in building your own public methods and objects, but that is fairly advanced coding and you can certainly build complex, effective scripts without loading external code.

[dublove]

Hi @rob day 

I'm sorry, maybe I didn't express myself clearly.
What I meant was: would using an external library be slower than calling it internally?
If I do have to use external libraries, which external call is better?

[rob day]

would using an external library be slower than calling it internally

There shouldn’t be any noticeable difference, but external libraries are going to be more challenging for a novice scripter. You should be able to load and evaluate a JSON file without calling an external library.