Closed hansthen closed 5 months ago
Interesting.
On the one hand, this adds considerably more functionality, but then it also moves away from the idea of simplicity (because now we'd be suggesting that users should expect to write inline JS)
What do you think about this/where it should be located @blackary?
I agree it increases the complexity. Perhaps we can put it under an advanced section and explicitly describe for what use cases this would be an appropriate solution?
If you're willing to add that page, I say go for it. Maybe in the docs Streamlit app in the sidebar, add a ## Advanced
heading, then add your page.
Docs are starting to get a little unwieldy now, might need to completely revamp them đŸ˜…
Docs are starting to get a little unwieldy now, might need to completely revamp them đŸ˜…
I created a new PR for it. What would you do to revamp the documentation? We use streamlit-folium at work. I can collect some improvement suggestions for the documentation.
Not sure what I'd do, just pointing out that we never took a real principled approach to this package. We just made it to demonstrate it could be done, and 400-something stars in, we should probably be more serious about it
Folium has a new
Realtime
plugin. (This is a bit like aGeoJson
layer, but it periodically retrieves the data from an external source.) This plugin allows javascript configuration elements through the use ofJsCode
. More javascript integration is on the way. UsingJsCode
allows users to bypass thest_folium
returned_objects
mechanism and return data directly.I think this is a useful addition for users as it gives more flexibility what data is returned. If you also think it is useful, I can add an example to the examples page and maybe also include it in the automated tests.
Below is a toy example. It shows the path of the International Space Station. If the user clicks on the marker, the current location of the ISS is returned.