omniJS :: What editors are people using for testing omniJS code?

What editors (and perhaps extensions ?) are people using when testing and adjusting omniJS code in the Omni Automation Console ?

Here, FWIW:

I don’t do much at present but my go to tool has been Textastic - on iPad OS.

1 Like

Of course – I was thinking a bit mac-centrically.

And I forget, can we install any standard formatters, linters, etc in Textastic ?

1 Like

I’ve been limping along with what little I’ve been able to do in BBEdit.

I see you’ve (apparently) moved from Atom.

Coming from AppleScript (and a little JXA in Script Editor), I’m frustrated by the Omni Automation Console. Why just that one line to paste into? How does one use it effectively in conjunction with a text editor?

How does one use it effectively in conjunction with a text editor?

The cycle of testing and updating is a lot easier with text editor:

  • if you assign any names in the Console directly, they will hang around unseen, polluting the global namespace, and and can interfere with other scripts run later
  • anything written directly in the Console is hard to find and modify.

The best approach is to edit your test samples in a template like:

(async () => {
    "use strict";

    const main = () => {

         // main script logic here
    };

    // --------------------- GENERIC ---------------------

    // reusable general functions here

    return main();
})();

and then:

  1. paste the whole thing into the console line
  2. hit enter to see what happens
  3. adjust and paste again …

( worth assigning the template to a keystroke or expansion string in something like Typinator or Keyboard Maestro )

The async keyword there is optional, but it allows you to use the await keyword in your script, which can make it simpler to deal with things like dialogs, and generally fetching data from outside the JavaScript interpreter)

2 Likes

FYI, As Rob helpfully points out, to avoid namespace issues you may wish to wrap code when entered in the Console. In the Toolbar page of the Console section of the omni-automation website is a plug-in designed to be put on the Console toolbar, and when it is clicked, will put a wrapper on the clipboard for you. Edit the plug-in to change the wrapper code to suit your needs. Cheers!

2 Likes

Perhaps worth clarifying the rarer contexts in which wrapping omniJS code in an “IIFE” wrapper (Immediately Invoked Function Expression) is optional:

  • You can safely “go without a mask” only if you are entering a one-liner which doesn’t declare any variable names.
  • you do need the (async () => { \\ code here })() wrapper if you give a value a name.

(Without the wrapper, any names you declare don’t go away, and lurk around invisibly – they are written into a persistent global name-space. They may create puzzling problems for scripts run later on.)


It’s good to see that the omni-automation site has made a step towards encouraging use of an IIFE wrapper – many of the examples on that site are still creating confusion, by showcasing unwrapped code and the use of the problematic and deprecated “var” keyword.

(This was rationalised, at one point, as a way of suppressing error messages associated with not using an IIFE wrapper)

Customers will decide for themselves whether installing a plugin just to get IIFE wrappers is worthwhile, but we should probably point out that the current draft of that plugin still has a few gaps and quirks:

Gaps:

  1. The IIFE wrapper which that plugin offers lacks the opening "use strict"; line, and this reduces the quality and informativeness of the helpful messages which customers will get from the JavaScript interpreter.
  2. The IIFE wrapper also lacks the async keyword, which enables use of the simplifying await pattern when dealing with things like user dialogs and data fetching. Without it, customers will have to use the more complex “promise chaining” methods.

Quirks:

  • The plugin itself is still show-casing the deprecated “var” keyword, which exposes customers unnecessarily to a particular class of puzzling bugs.
  • It also showcases the more complex and very rarely needed function() {...} form, in lieu of the simpler => arrow function syntax.
  • It sensibly introduces uses the default ; to clearly terminate statements, but confuses us a little by doing that inconsistently.

(ESLint – for which Visual Studio Code has a plugin – can immediately warn of, and in many cases automatically fix, this kind of thing)

1 Like

I’m sorry I don’t know. I need to experiment more with this. Unfortunately (?) :-) I have lots of creative projects on the go at the moment…

Good luck with the projects !

( My local macOS copy of Textastic doesn’t seem to have a general plugin interface beyond one for text snippets, I’ll pull out iOS and have a look )

1 Like