Whenever you start a HomeyScript and pass it args, they’re all sent as a single string. So you have to use some sort of delimiter. I changed from using space to using #, since that’s less likely to occur.
So all scripts have to start with the boiler plate:
let myArgs = args.split('#');
let foo = parseInt(myArgs[0]);
let bar = parseFloat(myArgs[1]);
I have and enjoy that app. It’s a good way to create a core library of flows, like an error flow where you can send caller-flow, log group and error message, and even have a bool for if you want to get a notification for that specific flow. It’s nice. But using HomeyScript is also good, so I don’t want to replace a few lines of code with ten new cards.
On a similar line to @homeypro solution, but without needing to parse the args every time is to add the following as the first line of the script: const flow_args = JSON.parse(args[0]);
then just use flow_arg.arg1, etc, to get the values.
You can also assign more meaningful names and use tags:
That increases readability and is equally many lines of code! I’m inclined to believe that that’s about the best we can do with how args are handled. Thanks for the help! And good stuff to you, too @homeypro!
Using common characters like : or ; as separator isn’t necessarily very bulletproof At least use something that is very unlikely to occur in tags, like newlines, NUL, or
True, and i need to keep the sequence and i need to manually convert argument types in HS.
But it gets the job done without ever creating a quote error.
As a senior developer, and someone who deals a lot with readability, I’d argue yours is the simplest way to do it, not a particularly readable way.
The problem here is that arguments can’t be split. Passing an array is silly, when we can never do anything but put an arbitrary string into the first element of the array. Now, HS’s inability to import code is in itself the crux of the whole thing. Code structure and maintainability goes out the window.
Over time I’ve removed myself from writing actually long scripts, and now I’m down to streamlining functionality that either has to be in code, or can remove like ten cards.
So, in our case, readability and maintainability needs to maintain a few things: How easy can I see what each argument is, how hard is it to make mistakes, and how does it appear as code?
I have an example that is:
Run script with arguments and return number:
Arguments:
Voltage, Power, Power, Power
I had to hover over each argument to see that the three “power” arguments were from 1) Power Target, a virtual sensor that has a Power value that’s how much power I can sustain for the rest of the hour 2) The total power used 3) the current power of charging my car.
With the rewrite, it now looks like this:
{“currentVoltage” : Voltage, “powerTarget” : Power, “totalPower” :Power, “chargingPower” : Power}
Now it’s a lot more readable. It also means that it’s straight forward to write the code:
let voltage = myArgs.currentVoltage;
let powerTarget = myArgs.powerTarget;
let totalPower = myArgs.totalPower;
let chargingPower = myArgs.chargingPower;
I could even simply use the myArgs.someArg in the code. This makes the boilerplate less prone to errors and easier to read and use. That makes maintainability better.
Also, wouldn’t JSON support using ’ to delimit strings, which means " would be fine in the strings? In the case of needing to solve that, you could do somethings different for those special cases. I doubt all your scripts need that ability. So you might be making your code too robust, which hurts readability and maintainability. I’d also suggest moving to using a repeating special character, like ### or something instead of [;:]. It takes way longer to write, and is obfuscating.
Not so much moot as incorrect, I guess Couldn’t remember on the fly. Still seems worth it to either handle a string like that outside a JSON object, even like