Hi Randy,
Thanks a lot for developing streamlit-folium. I've been using both 'folium_static' and 'st_folium' with great success. st_folium in particular is a highly powerful tool that I have found allows users to interact with the flexibility offered by folium in a whole new way.
I had a question regarding the EventListener/RENDER_EVENT currently implemented by the module (i.e., when the map component triggers a reload of streamlit and returns data).
As I have continued to use st_folium to display burdensome geographic data I have become acutely more aware that I would love flexibility regarding when the map element returns data to python. I understand the philosophy that a python script rendering a folium map should be aware of the boundary box, level of zoom, etc. that is currently being displayed by the folium map object. However, I also believe that information should only be returned to the streamlit page when it is pertinent to do so, as providing flexibility into when a 'rerun' of streamlit is generated enhances the user experience by mitigating load times.
Shapefiles can be burdensome to render and display, as they may be large objects. I have been using st_folium to develop reactive components of a larger app, where other tables, summary information, etc. has been dependent upon which displayed layers have been "last clicked" by the user.
Because this is one piece of a larger dashboard page, there is a lot that is re-processed when the st_folium component is interacted with. I've found that this has negatively affected the processing time of the dashboard whenever it is refreshed. I have been utilising the singleton and memoization (i.e., experimental_singletion & experimental_memo) capabilities as much as I can, however, I believe that further control into when the st_folium element triggers a rerun of streamlit will help in this process.
For example, if I have certain information displayed within the st_folium element, I only want to adjust the information displayed throughout the dashboard when a particular polygon/marker has been selected. An example of this could be polygons of different regions within the United States, where selecting a polygon provides state-level census information throughout the remainder of the streamlit page (tables, etc.). Under the current EventListener of st_folium, however, a trigger occurs if the user moves around on the map, zooms in, etc.
The boundaries and zoom currently viewed on the map is not of significant importance to the information output by the element of this example, as the user may want to get a closer look at the particular boundaries of a polygon by zooming in, move around on the map to view other polygons/markers, zoom out to obtain an aggregated view, etc. Selecting a particular polygon/marker, however, will provide greater information across the streamlit page regarding what they have just reacted to.
Under the current iteration of st_folium, any response to the map element will trigger a complete re-run of the underlying python script. Even if this trigger only takes a second or so, the event being triggered directly impacts the user, as the entire page will transition into a "light gray" as it re-runs the existing python script. This will then occur whenever the user moves around on the map or zooms in/out.
I would therefore love the capability to limit the conditions under which data is returned to streamlit, and a full rerun of the page is triggered.
I have been utilising memoization and singletons as much as I can, but if there are many polygons/markers presented on a st_folium map object, it may a non-trivial amount of time (i.e., more than a second) to re-render the map. Using folium_static will amend this issue, as the streamlit page will no longer re-run whilst interacting with the map. However, folium_static also removes the ability to select, identify, and summarise information within the greater streamlit page.
Including argument(s) that determine the events that trigger outputs to the streamlit page would provide a medium between the folium_static and st_folium functions. It would allow developers greater control regarding how a map element is interacted with. Warning against the potential downsides of disabling certain events could be considered within documentation, but I believe such capability would be of great benefit to both the st_folium function and the wider streamlit-folium and streamlit community.
Please feel free to contact me if you feel that this would be of value to your module, as i'm more than happy to assist in this development process.
Many thanks.