I believe I've encountered a bug in how Retool handles renaming variables. It clobbered a big chunk of my module. This is on self-hosted, version 3.178.0.
If you have a global variable foobar and any number of JS queries that accept foobar as additionalScope, references to that additionalScope within the code will be erroneously rewritten to point to the new global name, changing the behavior of the code.
Hello @Mark_Slade,
It seems like you've experienced an issue with variable renaming in Retool. This behavior can lead to unexpected changes in your code, especially if additionalScope references are automatically updated to the new variable name.
For debugging, consider the following steps:
1. Search All References
Look for all instances of foobar in your app, including global and additionalScope references.
2. Check Version Compatibility
You're on Retool v3.178.0 — review the changelog for any updates related to variable handling or renaming bugs.
3. Investigate the Code
Review all JavaScript queries where foobar is used. Note any unexpected behavior after the rename and back up original versions if needed.
4. Review Documentation
Check Retool’s docs for guidance on variable scope and renaming. Look for best practices and known caveats.
5. Report the Issue
If the issue persists:
@WidleStudioLLP , it would have been a bit more helpful if you could try to reproduce the bug first, rather than dumping what it seems a chat gpt generated response which, I may be mistaken, won't help @Mark_Slade much.
Hey @Mark_Slade, I was trying to reproduce this but was not able to do it. I saw a similar behavior in one of my apps and want to understand if this was the case, to make sure it doesn't happen to me again in the future.
Are you able to provide a short video of this? or simple steps to reproduce it?
Thanks!
@MiguelOrtiz Soooo.... I did put together reproduction steps, but in doing so realized that this is less a bug and more related to how Retool gives precedence when you have a global and additionalScope of the same name.
What happened to trigger this was:
tracks, and it was nicetracks, without really thinking about it.
This was where things went awry, not when I renamed the global, because at this point each query was referencing the global and no longer the additionalScope.allTracks.
all of my queries had all references to tracks replaced with allTracks. This was the correct thing to do based on my queries now referencing the global, but definitely not what I wanted.This boils down to Retool giving precedence to the global over the additionalScope when there's a collision. In JS, local scope takes precedence over module and global scope, so I am surprised globals take precedence here. I think if it were reversed, my code still would have been broken (some places I meant to reference the global), but it would have been an easier fix. Of course not duplicating names is the smart thing, but I'm often stupid.
Sorry -- including the video. I didn't mention this above, but of note in this video: when you have an collision between additionalScope and a global and invoke query1.trigger( { additionalScope: { scopeVariable: 'scoped value' } } ), the console produces an error about trying to assign setIn to 'scoped value'.
Ah yes, that all makes sense. Thanks for the detailed explanation Mark!