Programmable State Survey!

Hello Streamlit Community!

My name is Abhi and I have recently joined Streamlit as a Product Manager. One of my first projects at Streamlit is to start working on Programmable State. Previously, Thiago has also posted about Programmable State here: Programmable State for Streamlit and the community feedback has been super helpful!

We have started scoping the work and building prototypes. We are looking to interview users as well as sign up users for a closed beta program for Programmable State. (More in the survey)

Can you please spare 5-10mins to give us your inputs on Programmable State? - https://forms.gle/inH4iM322KJiw8Xh8 (Please leave a reply on the thread or add an emoji when you are done :slightly_smiling_face:)

7 Likes

Hi Abhi,

Sounds great!! I’ve answered the survey.

Thanks @PeterT :slightly_smiling_face:

:slight_smile:

Thanks @SimonBiggs! :slight_smile:

We’re continuing to collect community feedback so your response to our survey really help!

My pleasure :slight_smile:

If Streamlit’s history is anything to go by I imagine there will be a beautiful user-friendly API on the other side :slight_smile:.

1 Like

Just throwing this in here for inspiration: I recently started working on an analytics extension for streamlit (code, very much WIP at this stage), where I use programmable state to track when users change their input to a widget. So far, I’m using @thiago’s session state implementation to store a dict with all widget states (and update this whenever a user interacts with a widget).

1 Like

In discussions with @abhi and @kmcgrady the following example was thought of, spring boarding off of an example built by @kmcgrady:

A key design decision is that the state objects can be passed to streamlit widgets. And then by “linking” state objects together, this can cause Streamlit widgets to update each other upon user interaction. These links are undergone by calling the method link_to on the state object to be linked from, and passing it two arguments, the first the state object to link to, and second a conversion function converting the value of one state object to the second:

Importantly those conversion functions should be pure functions, with no side effects. They’re not designed to be used as callbacks, instead just converting the state objects and they should be able to be cached, for the same input, always producing the same output without any side-effects. If subsequent control flow is desired, the standard Streamlit approach can be utilised for tests based on those updated values:

And also, you are free to use standard Streamlit flow to have scenarios where you then update these state objects, this would result in the app to update (rerun) as normal, as well as the linked widgets:

It does mean that to access the actual value of the state object you need to call something like the following:

Keen to hear what people here think of it.

Cheers,
Simon

:smiley: