Coming soon: API update for Streamlit query params

Show the Community!
1

Hi all, an FYI that we’re working on an upgrade to Streamlit’s query params API. I’m sharing about it today to get feedback on the new API and help assess whether to release it as experimental_ or go directly to a stable API. Take a look and let us know what you think!

Read the full details of the new API and leave feedback in Github

TL;DR: Make query_params work more like session state. Return only the latest value (str) by default for a given key. get_all() method to return a list version with all keys.

st.query_params["show_map"] = True
st.query_params["selected"] = ["asia", "america"]
# URL: localhost:8501/?show_map=True&selected=asia&selected=america

# Note we convert everything to str return type
st.query_params["show_map"] 
st.query_params.show_map
# both return "True"

# In case of multiple values, by default we just return the last
st.query_params["selected"]
# "america"

# Use get_all() to return a list with all values
st.query_params.get_all("selected")
# ["asia", "america"]

st.query_params.get_all("show_map")
# ["True"]

Thank you!

4 Likes
2

Hi @jcarroll,
In my opinion: “go directly to a stable API”. Think that this is the great update.

I didn’t use this query params API yet, but will use them in the next weeks.

1 Like
3

it seems perfect and straightforward! Love it :balloon:

1 Like
4

Great!

I think this feature is really useful and I’m happy someone is working on it.

TL;DR I would suggest to add the possibility to configure custom functions for value conversion.

In my opinion, if upon writing the framework converts automatically all values to string, the framework should perform also the opposite and parse values (restoring”0” to 0, etc.) upon reading.
The actual “asymmetrical” behavior (one-way conversion to string) is not consistent and may be confusing for newbies.

I propose 2 possible behaviors to integrate:
A. upon writing accept only string values (and raise TypeError if trying to assign other types). Users should explicitly convert parameter values to string. This makes them aware of the limitation of using only strings in urls, protecting them from gotchas.
B. upon writing accept all primitive types, and convert them to string (actual behavior) but upon reading try to parse to int, float, bool, None, etc. and return that

I think the default behavior should be A, since it is “safer”, but it would be cool to have an option to configure behavior B, setting custom functions for conversions. We may have an option to set functions for all parameters, or only some of them.

What do you think? @jcarroll

5

Can we have tuple support?

st.query_params["{selected}{showmap}"] ==> ("True", "america")
st.query_params.get_all["{selected}{showmap}"] ==> (["True"], ["asia", "america"])

Similarly for assignment.

6

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.