JoshuaJADaniel commented on issue #34621: URL: https://github.com/apache/superset/issues/34621#issuecomment-3392958648
@SupersetOdT Yes, you are understanding correctly — it's a question of global vs per-point customizations. > via several boxes appearing in the Superset graphical interface or a single JS code box I did not want to add too much clutter to the UI, but using a single JS code box is a great idea to avoid that. > Attention in this case that the display settings in Superset are often made by trial and error. If we simply want to darken the color a bit, will we have to make a query in the database each time? This is a great point too, as I can imagine it would be tedious to update/requery the dataset for small, global customizations. For per-point customizations though, I feel it would be unavoidable since it makes sense to source the per-point customizations from the `properties` object (which would necessitate updating/requerying the dataset). > If one wishes to have several types of text, is it not preferable to create several Deck.gl Geojson and then assemble them via Deck.gl Multiple Layers? Had some time to play around with it, and yes, this could work if the user has a few types of text as you said. --- Okay, so your suggestion about JS code box interested me, because I believe it can solve both global and per-point customization requirements cleanly. Specifically, if we add a JS code box, the user could provide both global and per-point customizations as such: <img width="560" height="188" alt="Image" src="https://github.com/user-attachments/assets/cbf413d1-9e90-4a05-8b8d-993be1cc562d"; /> For global customizations, it would solve the issue you mentioned by allowing you to make changes without updating/requerying the dataset. Moreover, the user can do per-point customizations by grabbing properties from the `properties` object as needed. The only potential downsides I see are: 1. The user might not have the JS control feature enabled. 1. The user might not be comfortable with JS code. 1. The user might not want to read the deck.gl documentation. To address this, we could add a few basic controls to the UI that covers the basic use cases, and we let the JS code box act as a sort of "escape hatch" for more complicated use cases. What do you think of this idea? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
