The values held by urlParams seem to be inconsistent when there are no values passed in via the URL. I am seeing the following inside "run at startup":
In the above example none of the three URL parameters was supplied in the URL. It's not clear why some are "" and some are undefined.
The tab_bar is a different kind of component. Which probably explains it. However it also has a default value specified in its properties. I suppose the following sequence applies:
URL parameters are processed first.
Components get their default values from their points of declaration.
There is some code that is careful to not allow a default value in the definition of a component to override what was set earlier by URL parameter processing.
That seems messy and wrong. The components should get their default values first, then URL parameters should be applied. If URL parameters are missing the defaults values are there.
For the difference between undefined & "", that is component specific. The textInputs for example, default to "" if their values are undefined. However, a tabs component can actually have an undefined value for the selected tab.
That said, I agree with your assessment on the order of events and your feedback about url params. If I change the default value of the url param after the page loads, I get the expected behavior of the default being reflected in the url & the component. This does not appear to be a regression, but I will surface this with our team internally so that we can review the preferred behavior (and also document it better).
Would making this section dynamic based on whether there is a url param defined give you the behavior that you're looking for? (I realize it adds to the messiness )
That strikes me as a pretty good solution. It gives the programmer definitive control over what the value of something is when the URL parameter is defined or not defined. And it puts all the logic at the point where the URL parameter is set up.
The general problem is that certain values can be:
arrays which may be tested as having .length = 0
things which may be undefined
things which may be null
I think in some contexts all three could apply and yet they don't seem to. Pick the wrong one to test and your code doesn't work.
If you are not careful your proposed solution could still suffer from this if you make it so that in the following case:
foo is "undefined". That would be true...but to the code waiting for a value for foo these distinctions are not interesting.
Here would be a good place for retool to take a stand on how urlparams represent "nullness". You can say a missing urlparam and a urlparam having no value both result in the same value presented to the code that is going to read that value.
)