This is a declarative programming model similar to React. I'm surprised the analogy isn't drawn in the article.
"Streamlit assigns each variable an up-to-date value given widget states."
This line is interesting because it implies distributed state in each component (widget). Alternatively this could be framed in centralized state manager terminology.
"Each widget is provided with the current state of the application, and that state is also available to your script."
If you adopt this mindset you can separate the concerns of state and presentation. At first glance it appears that you need to extract state from widgets at the same point as they are added to the page.
(Please correct me if I'm wrong.)
I might not want to have a widget added to a page until much later in the script, but I want to have access to its state at the top of the script.
The value of the top level `props` parameter to a react component is it gives you access to all state wherever you need it, and disentangles this state from the arrangement of the page.
Thanks for that comment. You're exactly right: Streamlit adapts a React-like model. In fact, the connection goes deeper than the post describes. For example, to make it efficient to run the same script repeatedly, Streamlit does packet-level deduplication. If you generate a lot of data and send it to the browser, only small deltas need be sent to update the UI.
We have a list of future blog posts we hope to write and one of them is (cheekily) called "Streamlit is React for Python." ;) (Not quite true, more of an imperfect analogy!)
So it made me really happy to see someone drawing that analogy already. Thank you. :)
This is really cool. We've been thinking about these issues to create an image masking widget in Streamlit. Would be interesting to connect when we start down that path. If you're interested, please feel free to connect over discuss.streamlit.io. :-)
"Streamlit assigns each variable an up-to-date value given widget states."
This line is interesting because it implies distributed state in each component (widget). Alternatively this could be framed in centralized state manager terminology.
"Each widget is provided with the current state of the application, and that state is also available to your script."
If you adopt this mindset you can separate the concerns of state and presentation. At first glance it appears that you need to extract state from widgets at the same point as they are added to the page.
(Please correct me if I'm wrong.)
I might not want to have a widget added to a page until much later in the script, but I want to have access to its state at the top of the script.
The value of the top level `props` parameter to a react component is it gives you access to all state wherever you need it, and disentangles this state from the arrangement of the page.