Streamlit: Modifications in Slider to iterate over collection objects

[karankharecha]

Volunteer

Most of the data scientists were looking for this type of tool as it actually allows them to showcase the intermediate as well as final results of algorithms, dynamically. Delivering UI platform (web application here) with options to alter parameters and render the results accordingly is something that makes this tool _UNIQUE._
I, myself, am a data scientist with professional work experience and have been working with python since 2 years. I hereby, request streamlit developers to assign me the task of adding the feature to the slider and make it more robust. Below is the feature.

Problem / Feature

Slider works great when _values are in regular patterns_. Considering this _series of pandas_:
[_1896 1900_ 1904 1906 1908 _1912 1920_ 1924 1928 1932 _1936 1948_ 1952 1956
1960 1964 1968 1972 1976 1980 1984 1988 1992 1994 1996 1998 2000 2002
2004 2006 2008 2010 2012 _2014 2016_]

Here, this series consists of years, but intervals are not same, it _varies by 2, 4, 12 etc._
So, the problem is slider is not iterating values of the series or list or any collection object that is given.

Solution

MVP:
The smallest possible solution is to have a modification in the method that actually _iterates through the series/list that is given._.
All other functionalities of current slider should also be applicable to these series(s) and list(s).

Possible additions:
Having steps to skip iterations even in these series(s) and list(s) would be really useful.
For example:
series = [10, 40, 50, 90, 121, 800, 100]
step = 1
slider outputs = 10, 50, 121, 100

Additional context

Above image shows how slider should work even with user defined series(s) or list(s).

[arraydude]

Great idea! We're thinking about implementing this in Streamlit, but the API needs a little thought.
Although, it's possible that before any of this lands you'll be able to implement this yourself via custom components, which will be available in ~1 month.

[tvst]

Note to whomever implements this: please make sure the API and proto closely follow what we have for st.selectbox (as much as it makes sense to!)

In particular, please write a tiny little product spec

[karankharecha]

I want to implement this functionality and contribute.

[kmcgrady]

Hey @karankharecha ! It's awesome you want to contribute! I have been tasked for helping close this in the next week (ideally). If you are still interested in implementing this functionality, let me know. I can help out or take over if you have any starter code. If I do not hear from you, I will start implementing a solution. 😊

[karankharecha]

Hello @kmcgrady, Yes I would still like to contribute and I am interested. Could you please tell me how to get started?

[kmcgrady]

@karankharecha Awesome! I can direct you to some areas that can help you in coding. I'm new at this too, but here are some areas to consider.

Contributing to Streamlit - Use this for setting up the repo.

Changing the slider API, you'll want to start looking here.

Next, you want to set up how to communicate the messages from the python script to the browser. We use protobuf for that. You can edit the Slider proto file and run make protobuf. The recommendation is that we follow something similar to options in selectbox, so check out their proto to see how they set it up and how the python script sends that info over (near the slider code in python).

Lastly, you can edit the TypeScript code that affects the slider to show the intervals where possible (via this.props.element.get('<YOUR PROTOBUF NAME HERE>'). It might get a little tricky, but I think it's doable.

After that, we will want tests to verify everything.

How does that all sound?

If you find it good, can you let me know when I should expect a pull request? I figure a good start would be to implement the functionality, submit a pull request, get product feedback (is it the right API, docs, etc), then we can adjust and add tests after? I'm hoping we can have it close to wrapped up by the end of next week if possible.

[karankharecha]

@kmcgrady Hello, is there any channel where we can talk and interact?

[kmcgrady]

@karankharecha Hey, We currently do not have a chat setup. How is your progress? I might be able to set up some time to connect early next week.

[karankharecha]

@kmcgrady The project is working locally without any issues, there were few issues initially, but not now. Can we connect on Skype on Tuesday? If you're available.

[kmcgrady]

@karankharecha Sounds good. Want to publish a pull request so I can look in advance?

[karankharecha]

I am done with the backend part, but stuck in frontend. Can we chat on Skype and can I show the backend part and my approach?

[kmcgrady]

Hey @karankharecha I figure I'd check in and see how are you doing on this?

[kmcgrady]

Throwing a product spec here. I think the issue discussion illustrates the task. More or less, it's using a slider across a list of non-numeric or inconsistently stepped data. Above. Here's my Product Spec:

Changes

1. st.slider() takes in two arguments (similar to selectbox):
   
   
   
   • options - a iterable object (list, tuple, numpy.ndarray, pandas.Series, or pandas.DataFrame)
   
   
   • format_func - function to convert each option for display (conflicts slightly with the format parameter, which is a string. Thoughts?)
   
   
2. st.slider() passes to proto [str(format_func(option)) for option in options]. It sets default values with options.index(value). A ValueError is raised if the value is not in the formatted option list.
3. Slider UI creates a slider with min=0, max=len(options) - 1), step=1 since the slider needs a consistent step. It iterates over the index.
4. Set Slider's aria-valuetext to options[value] for single values, and "{options[0]} to {options[1]}" for range (we will apply these for dates too since screenreader output does not make sense.
5. Server side, formats options to send down, sets default min/max values, and translates slider values to option.

Side Effects and Edge Cases

• Values must be set as a string.
• A slider with options=[] produces a degenerate slider (No steps and produces 0)

[tvst]

Just to be clear, for those who are following from home: this spec hasn't been approved yet. But hopefully soon!

Our process is:
1) Someone (usually an engineer) proposes a spec
2) The product team works with the engineers to review/update/approve the spec
3) We work on it.

This work is currently in step (2), i.e. being reviewed by Product.

[tvst]

@kmcgrady thanks for writing this up. I'm having a hard time understanding the proposal above, though. Can you expand on it a bit?

In particular:

1. When you say this:

   st.slider() takes in two arguments (similar to selectbox):

   • options - a iterable object (list, tuple, numpy.ndarray, pandas.Series, or pandas.DataFrame)
   • format_func - function to convert each option for display (conflicts slightly with the format parameter, which is a string. Thoughts?)

   ...can you write what the final st.slider API will look like? For example, are you saying sliders will no longer take a min, max, etc? But just an options argument? Or are you adding more options to st.slider?

   My impression is we should do the latter, but this means the st.slider API is getting a bit too complex. I'll only know it when it's all written down, though.

   If it turns out that it is getting too complex and that complexity is not easy to address we may want to pull this into a separate st.option_slider command.

2. What would the browser-side user experience be when you have a slider where the data has different step sizes, like options=[1, 2, 10, 100, 103] ? Would the rendered slider have difference step sizes too?

   My take: no. The step sizes would always be equal. Basically we would treat the values in the list as nominal values (i.e. labels) rather than quantitative.

3. And what if the options are out of order, like options=[10, -5, 2, 7, 0] ? Would the rendered slider sort the options?

   My take: we don't sort. Again, we just treat the list as a list of nominal values. And because we can't know what the logical sorting of nominal values are, the developers are in charge of sorting it themselves.

4. Here

   A slider with options=[] produces a degenerate slider (No steps and produces 0)

   My take: output should be None rather than 0.

5. And here

   Values must be set as a string.

   I'm not sure what this means. Are you saying we wouldn't support options=[0, 1, 2], but would only support options=["0", "1", "2"]?

   My take: we should support _any_ value, but we'd coerce all values to strings using str() before serializing into the proto.

6. What would the returned values look like?

   For example, what should st.slider("my slider", options=["some string", someObject, 1234]) return?

   My take: we should return the actual element that was selected, mimicking the behavior of st.select("my selectbox", ["some string", someObject, 1234]). So if you select the 1st item in the example above, the return value should be "some string" (a string), and for the 2nd item we'd return someObject (the actual object), etc.

As for the rest of your post, it focuses more on eng design rather than product design, so I'll refrain from commenting on it here (even though I have opinions there too!). For that part, can you write a little eng design doc once the product spec settles down?

[kmcgrady]

@tvst here's my response.

1. Two additional parameters:

st.slider(
    label,
    min_value=None,
    max_value=None,
    value=None,
    step=None,
    format=None,
    key=None, 
    options=None,
    format_func=str)`

Your call on whether it's getting too complex.

1. Agreed. The browser slider can only have a consistent step, so we need to convert a set of data with an inconsistent step, to one that has one. Hence the method of making a slider from 0 to the number of options - 1. Step is consistent, but a conversion to a value to submit back is done on the server layer.
2. Agreed. given (2) we assume the set of options are dictated to the user writing the script.
3. Fair. That's easy.
4. That seems reasonable. If we want to continue using format_func, we'd do str(format_func(value))
5. That works too.

I can convert my current code change to modify this structure and let you comment on it with regards to engineering design.

[treuille]

<philosophical musings>

1. My feeling is that each argument of a function should be independently settable and the resulting function call should “make sense.”
2. Equivalently, when your kwargs lead to docs which are like: _argument X takes precedent over Y, and you can’t set both Z and W_ then it sounds like you’re secretly trying to superpose two functions on top of each other!

</philosophical musings>

Therefore, would propose that we split this in a separate function called select_slider which mimics the selectbox semantics.

[kmcgrady]

Final API based on Pull Request. Separating it out made things easier.

st.select_slider(label, options=[], value=None, format_func=str, key=None)

The only difference from the discussions above is that a degenerate slider (ie options=[]) raises an StreamlitAPIException because downstream problems in the frontend made little sense to fix for.

@tvst for your interest.

[kmcgrady]

I should mention to @treuille that while product-wise the functions are separate, engineering-wise they display the same component (a slider). I think there are better wins to merging the UI to maintain consistency.

[treuille]

Perfect! This is great, @kmcgrady! 🙏

[kmcgrady]

Everything is merged and will be out in the next release. Thanks @karankharecha for your help.