In these two images, the automation achieves the same goal:
The first shows how I naturally built the automation with separate calculation fields:
The second groups the lines into execute script fields:
I’m sure the above could be further streamlined into a single ‘Execute a script’ field. However, is one method better than the other in terms of speed of execution, server load, etc.? Or is it just a matter of personal preference? For instance, I assume that @tim or @Ben amongst others, with a coding background, would aim to use as few script fields as possible, while I, coming from a no-code background, naturally divide it into smaller blocks. Is there something else I might be overlooking?
@Jason I’m also coming from no-code background and my guess is that less action (more code) is better option. I do sometimes go through automation and see too long actions and play around with code and see that the same result can be achieved with a little more code. Still learning…
In terms of speed my guess is that more code / less actions is better.
Hope Tim & Ben will get their opinion.
Thanks for sharing @Jason and also for your input @tomaz!
One might argue that both options have their pros and cons in real world scenarios. Regarding computation time -while in theory more actions yield a longer runtime for workflow executions - in reality this should not make a difference that is measurable or “feel-able” by users.
What I like about your first option is the “single responsibility” that makes each block really easy to reason about. This is a principle that we do also use when solving engineering tasks in building and enhancing Tape. Take a big challenge, divide & conquer it down to small and easy chunks of work that are not complex anymore → solve them, continue.
In this case you can even name your actions like in your example for the first block, use something like “Compose start param” by clicking on the action label - one may then even collapse those actions by clicking on the left arrow. This way, you will see on first look what happens (requirement), without needing to see how it is done (implementation).
Sorry for the geeky parts, hope this helps you a little!
Cheers & happy scripting
Thanks for this @Tim it is always good to hear the best ways from the people designing and building the system
I think the ‘single responsibility’ is the reason I naturally put together an automation in that way as I can see each stage as I go. However, it does lose the ability to
Interestingly I thought I had done this:
but obviously hadn’t by the stage of taking that screenshot .
One other reason for breaking it into separate blocks is that it makes it look less daunting/more friendly to someone not used to seeing code - which I guess thinking about it could also be a disadvantage
Thanks again for taking the time to give your opinion