Add geoman plugin - #304
Conversation
Introduces a Geoman class (wrapping @geoman-io/leaflet-geoman-free) that provides drawing, editing, dragging, cutting, and rotating of shapes. Returns geoman_drawings (all features) and last_geoman_drawing to Python. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
# Conflicts: # streamlit_folium/__init__.py # streamlit_folium/frontend/src/index.tsx
|
Need to do some research here, looks like this is a leaflet plugin, not a folium one? |
|
@randyzwitch This is a Folium plugin that I added some time ago. It is already possible to add it to a streamlit folium map. I provided example code here: #248. The main drawback is that the user needs to provide event handlers (= javascript code) to integrate with streamlit folium's event handling system. Ideally I would like to see a system where the plugins are decoupled from streamlit folium. (I.e. you can add new folium plugins to streamlit folium without changing the core streamlit folium component (like you do here). This is what I started working on in my draft PR, before I got stuck. (I was also waiting for the new streamlit component API would be released). I am not sure what is the best approach here. We could
So my question to you is: do you see this as a worthwhile goal to work towards (to decouple the streamlit-folium core from the individual plugins). And if so, what approach of the three above items would you prefer. Sorry if this is hijacking your PR for the geoman plugin, but I think maybe we can take a step back to formulate a longer term architectural vision for streamlit-folium. If you are interested maybe we can setup a call to discuss with Blackary as well? |
|
TBH, my vision for this plugin is similar to Streamlit which is "things should just feel magical". In that sense, people who don't know JavaScript (and I am one of them) should be able to just use Folium and have it do what they are expecting, and in this case, more because Folium itself doesn't have the bi-directional data functionality (AFAIK). I don't mind occasionally adding a bit more plugin code here, if it removes the need for users to have to hope they copy javascript correctly into their code. The only downside is that as new plugins happen, this package needs to update to include them. So far, that happens quite infrequently. If there's a way to factor that out such that adding a new package to package.json makes it automatically add the data to the returned Streamlit data, I'm definitely open to that. But I definitely don't want to go in the direction of making the most beginner of users have to inline JavaScript in Python, as I think that excludes too many beginners. |
|
And of course, if there is a way to do that AND make it so power users can pass custom JavaScript code to the plugin, that's a net positive as well. But those users probably can just use React or another JavaScript framework, so I don't want to improve things for power users at the expense of beginners. |
|
In general I think that the v2 system (https://docs.streamlit.io/develop/concepts/custom-components/components-v2) would have a lot of benefits for this component, and would make it a lot easier to, among other things, add new input and output types without needing to mess with the internal js of the package. Native callbacks would become much easier, and I think in theory we could remove a lot of the custom code for handling various plugins. I'm not entirely sure if it would allow you to add in arbitrary plugins without changing the underlying code at all, or if that would require new packages that subclass Folium, or what. I'd be interested in a conversation to discuss long-term architecture, either a call or async. |
Fair enough, I see your point. You want to take Folium maps and they should "just work" in streamlit-folium. |
I consider myself one of those power users. I like to use Folium maps (since Python is my main language) with a little Javascript. For me switching to React is not an option. I want to keep using Folium in streamlit. In 2024 we added first class javascript event handlers to Folium specifically to add bi-directional communication. The way streamlit-folium adds event handlers interferes (a bit) with this mechanism. I would like it if somehow streamlit-folium could use the native Folium event handlers. But as said, I see your point how we should not improve things for power users at the expense of beginners. I believe (but this is more faith than science) that we if we think hard enough we can come up with something that will accomplish both. |
|
Let's see what @blackary's PR gets us, and see what we can work towards from there. I definitely don't want to make anything harder on Folium folks any more than I do for the Streamlit ones :) |
3 participants
No description provided.