Given a component called portfolio (for example a text input box) with a .value property....
Refactor a Javascript query; add additionalScope parameters and call one of them portfolio.
Inside that query a reference to portfolio.value is modified to portfolio.
Callers of trigger do things like this:
foo.trigger({additionalScope:{portfolio:portfolio.value}});
This fails with a mysterious error:
Cannot create property 'setValue' on string '<some uuid>'
Where the text component portfolio is currently holding <some uuid>.
If the additionalScope parameter is renamed to something that does not conflict (for example, p1) then everything works fine.
This seems bad. additionalScope is not actually creating a real "scope".
To make matters more complex I have seen this "work" sometimes. Possibly it works inside {{ handlebars }} or if the name conflict is with some variable not a UI component. Not sure.
Fixing this may be very complex and long term but Retool could do a couple of things short term to help.
- The IDE "helps" construct additionalScope and it could more helpful in warning the user of a conflict. This could be where additionalScope parameters are created and also each time the user is completing a
.trigger({additionalScope:{...}})expression. - And, the error message
Cannot create property 'setValue' on string '<some uuid>'could be less opaque.
One thought. When there is a conflict, inside the scope where an additionalScope parameter foo has the same name as some global entity named foo then rather than telling the user they can't do this you could allow additionalScope.foo to reference the local parameter and foo to reference the global entity.
A related suggestion. I think the following semantics are not currently "guaranteed" but they would be useful.
additionalScope parameters could be guaranteed to be undefined if the .trigger expression fails to supply a value. This would allow the author of code to introduce seldom used parameters with defaults, and callers to ignore them unless the defaults are not suitable. I know this "can be done" because I think I have code doing this but it seems clunky and it didn't work the 2nd time I tried to use the technique. The following example seems to work: the additionalScope parameter is called singleton, the default value is false and it is seldom overridden:
const _singleton = (typeof singleton !== "undefined") ? singleton : false;
Inside the body of the code the value _singleton is guaranteed to be either true or false whether the caller defined it or not.
A related question: is the order of parameters where defined completely decoupled from the trigger expressions where they are passed in?
