Jump to content

Modules: Difference between revisions

Yagton (talk | contribs)
Created page with "Modules make it possible to reuse code for OWOT scripts, very similar to how <code>require()</code> works in [https://nodejs.org/en/ NodeJS], although in a more decentralized manner. Modules are hosted on [https://github.com/ GitHub], meaning absolutely anybody can create modules for others to use. They can be loaded using the <code>use(identifier: string)</code> function, which takes in an identifier and returns the module’s exported variable(s). Identifiers are in th..."
 
Lemuria (talk | contribs)
No edit summary
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
Modules make it possible to reuse code for OWOT scripts, very similar to how <code>require()</code> works in [https://nodejs.org/en/ NodeJS], although in a more decentralized manner. Modules are hosted on [https://github.com/ GitHub], meaning absolutely anybody can create modules for others to use. They can be loaded using the <code>use(identifier: string)</code> function, which takes in an identifier and returns the module’s exported variable(s). Identifiers are in the format <code>user/repo@version/folder/file.js</code>; version can be either a git tag or commit id, is entirely optional (although highly recommended), and [https://semver.org/spec/v2.0.0.html semantic versioning] is fully supported.
'''Modules''' make it possible to reuse code for OWOT scripts, very similar to how <code>require()</code> works in [https://nodejs.org/en/ NodeJS], although in a more decentralized manner. Modules are hosted on [https://github.com/ GitHub], meaning absolutely anybody can create modules for others to use. They can be loaded using the <code>use(identifier: string)</code> function, which takes in an identifier and returns the module’s exported variable(s). Identifiers are in the format <code>user/repo@version/folder/file.js</code>; version can be either a git tag or commit id, is entirely optional (although highly recommended), and [https://semver.org/spec/v2.0.0.html semantic versioning] is fully supported.


<span id="how-to-use-modules"></span>
<span id="how-to-use-modules"></span>
Line 15: Line 15:
<syntaxhighlight lang="js">const foo = use("./foo.js");
<syntaxhighlight lang="js">const foo = use("./foo.js");
const bar = use("../other/bar.js");</syntaxhighlight>
const bar = use("../other/bar.js");</syntaxhighlight>
<span id="how-do-i-testload-modules-locally"></span>
== How do I test/load modules locally? ==
If you’d like to load local code as a module rather than running from a repo, such as for testing purposes, simply pass a function to <code>useLocal(func: function, identifier: string)</code>:
<syntaxhighlight lang="js">const localMod = useLocal(function(isModule, currentModule) {
// [insert your module here]...
}, "some_identifer");</syntaxhighlight>
The identifier for local modules is not subject to the same strict requirements as remote identifiers, but if you want relative imports to work, it must be the same as if it were in the remote repo.
<span id="how-can-i-check-if-a-module-is-loaded"></span>
<span id="how-can-i-check-if-a-module-is-loaded"></span>
== How can I check if a module is loaded? ==
== How can I check if a module is loaded? ==


the <code>isModuleLoaded(identifier: string)</code> function is just for this, and will return a boolean value depending on whether or not that module has been loaded or not. Keep in mind that modules are only loaded once and that same instance is shared by everything which imports it, so it is redundant to do this check if you are simply going to import if true, just make a <code>use()</code> call; this is primarily useful if you want to add ''optional'' functionality if another module is loaded without requiring it.
The <code>isModuleLoaded(identifier: string)</code> function is just for this, and will return a boolean value depending on whether or not that module has been loaded or not. Keep in mind that modules are only loaded once and that same instance is shared by everything which imports it, so it is redundant to do this check if you are simply going to import if true, just make a <code>use()</code> call; this is primarily useful if you want to add ''optional'' functionality if another module is loaded without requiring it.


<span id="how-do-you-write-modules"></span>
<span id="how-do-you-write-modules"></span>
Line 64: Line 74:


return { baz };</syntaxhighlight>
return { baz };</syntaxhighlight>
[[Category:Documentation]]