Code Order Shouldn't Matter

All the below are with respect to items placed on the sidebar

I have some filters that depend on all other filters. For example, if I have a dataset for cars and car types, I want to filter by either of them and have the other’s options reduced. Here’s an example:

CARS = ['BMW', 'Audi', 'Ford']

---- USER FLOW ----
User selects BMW.
TYPES options are reduced to “SEDAN” and “COUPE” because there are no BMW trucks in this example.

User is happy :slight_smile:

<< Here’s where it breaks down >>>
Now the user wants to go the other way around. Clears the CARS filter and selects “SEDAN”.
So the CARS dropdown should update to [’FORD’ and ‘AUDI’], but it doesn’t! It still displays all options.
<< Here’s where it breaks down / >>>

----- END OF USER FLOW ----

I think this happens because Streamlit compiles vertically, but, as Javascript would do, it’d be cool if it updates the options based on the actual objects’ contents.

1 Like

HI @landmann,

That approach is actually on the product roadmap. When writing Streamlit we decided to first focus on the “getting started” use-case. Our goal was to make it extremely easy to build UIs, even if this meant the set of UIs you could build was actually limited. Now that Streamlit is out in the world, we’re working on expanding the use cases.

So whereas you can only do something like the following right now, where the object both writes and immediately returns the value:

 x = st.slider(...)

In the future you could do something like this:

# create a slider object
slider_obj = st.Slider(...)

# edit the value of the slider
y = slider_obj.value + 10

# [do more things…]

# finally, render the slider

…and, of course, we’d still support today’s API as a syntax sugar over the new object-based API.

ps. If you need a solution right now, it’s possible you can put something together using the st.rerun hack from here:

1 Like