I was curious about the deprecated: search tag in KM11 so I tried typing it into the KM search bar. To my surprise, all my macros with Execute a JavaScript for Automation actions came up. (I have a lot of them.) I assume that's because those actions don't use the new JavaScript Modern Syntax.
I can see how Modern Syntax is cleaner and more convenient than the old syntax, and I'm happy to use it going forward, but do I need to rewrite all my existing macros to use it? Should I be concerned that the old syntax will break on KM12? Until now I can't remember having any backwards-compatibility issues with KM.
Also, @peternlewis, the changelog includes this:
- Default new Execute JavaScript actions to modern syntax and include no variables.
but when I create a new Execute JavaScript action it defaults to Modern Syntax and Include All Variables. So it seems like either the documentation is wrong or the action doesn't work as expected.
If I have understood correctly, the issue is simply that the old approach involuntarily exports all of your KM variable name:value pairs into the global JS namespace, where it's not impossible for another process to read them (particularly in the context of a browser).
Given that lower level of security, it's clearly appropriate to deprecate the old approach and encourage the new.
My guess, however, is that there is not much danger of the old approach ceasing to run, at least not in KM11 ... @peternlewis ?
i.e. sensible to make (and encourage) the transition, but no obvious obstacle to doing it gradually, in due course, or only, at least for the moment, with new macros.
( For new macros, of course – the new approach greatly simplifies the business of reading KM variables from within JavaScript )
1 Like
Probably not. I have no plans to remove support for the old syntax.
The new syntax is better and safer and you should switch over to using it, and the deprecated: search tag is there to help you find the ones you haven't changed yet.
- Default new Execute JavaScript actions to modern syntax and include no variables.
Yeah, I think I changed that. The new syntax means including them is safe so I think that's why I left it including all the variables.
2 Likes
In the old syntax, use of local_ variables required a little hoop-jumping to obtain the ID of the running Keyboard Maestro Engine instance.
If I wanted to read a data series in a Keyboard Maestro string value like:
and obtain the maximum value in that series, I might write something, in the old syntax, like:
(() => {
"use strict";
const
instance = ObjC.unwrap(
$.NSProcessInfo.processInfo.environment
.objectForKey("KMINSTANCE")
) || "",
values = Application("Keyboard Maestro Engine")
.getvariable("local_DataSeries", {instance})
.split(/\s+/u)
.map(Number);
return Math.max(...values);
})();
Whereas in the modern syntax:
- The IIFE
(() => {})() wrapping (to get a local namespace) is provided for free, by Keyboard Maestro, under the hood, without our writing it out, and
- we can read the value of our
local_DataSeries variable directly, by just adding a kmvar. prefix. (No need to obtain an instance identifier)
Now with the pull-down menu option set to Modern Syntax,
we only need:
const
values = kmvar.local_DataSeries
.split(/\s+/u)
.map(Number);
return Math.max(...values);
Old syntax vs new Macro (v11.0)
Old syntax vs new.kmmacros (3.4 KB)
2 Likes
More succinctly, for those who are used to JavaScript, in the Modern syntax for these actions:
- We are already safely inside an IIFE, and have to explicitly
return any value from that local scope to Keyboard Maestro
- there is, within the local scope of that enclosing IIFE, a predefined
kmvar object, the keys of which are KM value names (including local_ value names)
Old syntax:
Modern syntax:
2 Likes
The documentation on the action is correct, and I have updated the Whats New.
2 Likes
