I'm using OLN for some basic namespacing in a few javascript files. The "logical hierarchy" of those files is something like this:
-main.js
-somefile.js
-otherfile.js
-....
main.js manages stuff that all pages need, but then depending on the specific page loaded somefile.js or otherfile.js might be loaded (or neither).
In main.js, this is the syntax:
main.js
var mainjs = {
someobjects: [baz],
// more stuff
}
Depending on what page is loaded, other javascript files are loaded. They might add objects to that list, like so:
somefile.js
let foo;
let bar;
$(function() {
console.log( " somefile.js ready!" );
mainjs.someobjects = mainjs.someobjects.concat([foo, bar])
}
If I look in the console after page load, I can see that within mainjs.someobjects, I have those 3 objects. "baz" is defined and the 2 others I added are "undefined". That's fine.
However, when I later initialized those 2 objects from somefile.js (user clicks something), then in the console I can see that foo & bar are both defined. However, in mainjs.someobjects, the 2 objects are still undefined.
I thought those would be passed as reference, but apparently I was wrong. Basically the issue I'm trying to address is that I have a few different somefile.js which may create different objects (dataTables actually) but they fetch the data (ajax calls) only when the tab that contains them is shown. Then I need to adjust the columns widths based on the data. A known issue with datatables, when the html is created before the datatable is populated. A call to table.columns.adjust() is needed for that to happen.
So:
mainjs still undefined and who I can change my structure so that when those variables are later assigned to objects, they actually reference the object?I thought those would be passed as reference, but apparently I was wrong.
Yes, JavaScript is a purely pass-by-value language, other than something JavaScript native modules ("ESM") do.
It sounds to me like you want to use ESM. In ESM, when you export a module-level binding (loosely, "variable") and another module imports it, the other module has a read only live binding that links it to the original exported one. That means that when the module that imported it uses it, it sees the then-current value of the source binding (not the value it had when it was exported).
So if you were using ESM and did:
export let foo;
export let bar;
// ...code here that asynchronously or periodically updates `foo` and/or `bar`...
Then a module importing them:
import {foo, bar} from "./some-module.js";
...will see the current values of foo and bar via those live bindings.
If you don't want to use ESM for some reason, you can export an object with properties for foo and bar, and have the other code using that exported object. Since the object is stable (we don't replace it with a different object), code using it can reliably access its foo and bar properties and see their current values.
Basically, in somefile.js:
const meaningfulName = {
foo: undefined, // Or some more meaningful initial value
bar: undefined, // Or some more meaningful initial value
};
$(function() {
console.log( " somefile.js ready!" );
// Just FWIW, I probably woudn't use an array for this, I'd use an object
mainjs.someobjects = mainjs.someobjects.concat(meaningfulName);
}
Then code using that object would use its foo and bar properties, and always see the current value of them.