Closed kingo55 closed 4 years ago
It's really hard to handle this, currently we're using the shared codes as a js Object, then we can call it in recipe's code by test.options.js.xxx(). For a js file, it requires js statments like variable definations. But the { aa:"", getXHR: function(){} } is not a js statement. That's why we see errors in IDE. I also tried changing the extension name to .json, but VS Code still show errors, because xxxx: function() {} isn't valide json.
The way I can think of is: shared.js:
function shared()
{
return {
getXHR: function()
{
},
...
}
}
Then we call it in recipe code:
var sharedObject = test.options.js();
sharedObject.getXHR();
...
I agree with @allmywant's suggestion of changing the structure of shared.js to a function which returns exposed functions.
It will basically require us to:
@allmywant @dapperdrop - agreed, this sounds like a good solution to me as well.
We have to do this currently in Google Tag Manager for some custom JavaScript functions. Is there anything we need to worry about whilst migrating old tests objects over?
Closing this one as it sounds like this is the way forward:
https://github.com/mint-metrics/mojito-js-delivery/issues/21#issuecomment-549629640
Whenever we build complex tests with large shared code objects, we have a lot of code, variables and functions inside
test.options.js
. This is a good practice to minimise page weight.However since the structure is a JSON that includes JS code, we often get linting errors whenever the editor parses our valid test objects:
This makes it harder to work inside the shared code sections and spot legitimate errors in the code.
How can we handle for this? Is this a Mojito problem or a configuration problem with our editors (e.g. VS Code)?