\u0000I have revised [Mapbox-Flow]
(https://mapbox-flow.herokuapp.com/) so it is now based a PolymerTemplate.\n\nI am now pondering what is the best way to represent the objects that the Mapbox JS component needs.\n\nI see the following options:\n\n1) The ‘official’ Vaadin way: Defining them as elemental.json.Json objects. This allows for calls where call and parameters are separated:\ngetElement().executeJs(\"this.map.addLayer($0);\", layer);\n\n2) Defining the objects as extensions of org.json.JSONObject, which makes them easily serializable via .toString()\nSeparated calls, as under 1), do not work, but the serialized String form can be directly included in the method call:\n getElement().executeJs(\"this.map.addLayer(\"+layer.toString()+\");\"); // or implicit without toString()\nThis works without a problem.\n\n3) Defining a POJO model with support for serialization by annotating properties with com.fasterxml.jackson.annotation.JsonProperty.\nI see this approach used in ApexCharts-Flow. Downside is that this requires several calls for one function, e.g.:\n\n getModel().setSourceId(sourceId);\n getModel().setSource(source);\n getElement().callJsFunction(\"addSource\");\n\n(In the last call, the JS wrapper uses the locally set this.sourceId and this.source in the addSource() method.)\n\nProblem with the last approach is that when scheduling multiple calls of the same kind (e.g. addLayer()), the order of the JS method calls is not guaranteed and indeed gets mixed up. \n\nIs there anything else to consider besides personal preference, e.g performance or upgradability…?\n\nMuch appreciated. \uD83D\uDE4F\uD83C\uDFFB