Okay this one tripped me up so I thought I should point this out more clearly for those who are old and slow like myself.
When writing a transformer, you must enclose all references to Retool scope in double curly braces {{}}. This is different than js queries which run within the retool scope out of the box. This is hinted at in the documentation through examples but is never clearly pointed out.
So you can't just copy/paste your query code over to a transformer when you realize that it is the more appropriate option, like I tried to do.
Maybe there is a way to inject or reference Retool's scope into your transformer like var rt = Retool and then you can just type rt.myTable.selectedRow.data.forEach(...) which is cleaner than var data = {{myTable.selectedRow.data}}; data.forEach(...)?
2 Likes
Another tip about proper use cases for transformers I discovered that isn't spelled out in the docs clearly enough for those of us of the more mentally addled persuasion. 
Transformers are reactive and will run on page load and whenever the values change so you can't really use them like functions. So if it OK that they just run whenever until you get around to needing their bounty, or you always want their .value nice and fresh just in case then transformers are your ticket. If you only want the code to run on demand, then it seems js queries with liberal use of onSuccess are your effective function replacement.
Other options I have yet to discover on my climb up the Retool learning curve?
You're definitely correct that are docs are little sparse in the JS transformer vs query realm (as well as other realms). I'm currently working on some material to make Retool's learning curve a little more climb-able, and I'd love to hear about any other blockers for you!
3 Likes
For me, transformers are unnecessary, and worse for performance. If queries can automatically run on input change, transformers can be deprecated. A big advantage of manual query trigger is, on page load, only running those that are actually needed, while all transformers currently always run on page load.
@victoria, That chart is helpful thanks!
@hadrian. Transformers look like would be useful in place of the inline JS you would place into conditional parameters like Hide When True or Disable When True or Selected Tab Index. When the logic gets too complicated to want to edit in a little text box is a primary use case for transformers as far as I can can tell. I don't think queries can do that as they are promises and so don't reliably run in a known time frame? If your conditionals are are simple then transformers are overkill.
I have not needed them for that yet, but I might soon. Calling these "transformers" for that use is a bit confusing and is why I didn't see them as an option right away. Using a transformer to well, transform the return value of a query is something I do and the name makes sense there. If you do the same type of transformation on multiple queries then you of course want to keep it DRY and use a single transformer function there.
Maybe call them Return Value Functions so the name is more descriptive of what they do and less specific to a single use case? You sill have a transformer parameter in your query and you can call a Return Value Function from there if you want to.
