urlParams, odd behavior

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":

These URL parameters are all specified in the same way:

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:

  1. URL parameters are processed first.
  2. Components get their default values from their points of declaration.
  3. 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.

Hi @Roland_Alden,

Thanks for this report!

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 :confused:)

In the screenshot above, I want the component to be defined by the url param, but if the url param doesn't exist, default to the string 'one'

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:

https://foo.retool.com/apps/.../myapp#x=0&foo=&y=42

foo is somehow null or zero length or ????

and in this case

https://foo.retool.com/apps/.../myapp#x=0&y=42

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.

It's a thought.

Thank you for the detailed feedback, @Roland_Alden! I definitely agree that this feature could use some more clarity + supporting information.

As you noted, it's currently very tricky to sort out how the different data types/components work with this feature. It looks like our team is just starting to pick up some url param bugs, so I'm hoping we can make this feature easier to use. I've shared your feedback internally with the teams working on this