[GitHub] mistercrunch commented on issue #5680: [SIP-5] [Embeddable Charts] Decouple charts from slice and formData

[GitBox <gi...@apache.org>]

mistercrunch commented on issue #5680: [SIP-5] [Embeddable Charts] Decouple charts from slice and formData
URL: https://github.com/apache/incubator-superset/issues/5680#issuecomment-414512619
 
 
   Note that the chart function's signature is actually `function deckGeoJson(slice, payload, setControlValue)`. `setControlValue` is a hook to a Redux action that allows for the chart to modify controls. For instance the deckgl visualizations zooming/panning set the ViewportControl. The adaptor function needs to receive/dispatch it.
   
   To make this frontend visualization plugin possible, we'll need to figure out how to get rid of the visualization-specific backend code in `viz.py` over time, to make sure that visualizations plugins are fully defined as Javascript. One easy step forward is to move the backend's `query_obj` code, which takes `form_data` as input and returns a query object (simple logic). The `get_data` method is probably harder to migrate to the backend (takes a dataframe and returns nested objects), but it can probably be generalized quite a bit, so that it's not visualization-specific as much as ordering pandas-like operations on the result set.
   
   So I'm wondering where these new frontend methods should live. I'm guessing you were thinking about export the adaptor and using this as an the interface between `chart` and the visualization plugin. Now I'm thinking we may want to export a more complex object.
   
   ```js
   export const visualization = {
     adaptor,
     queryGenerator: (formData) => {
       return generateQuery(formData);
     },
     dataframeOperations: (formData) => (['pivot_table',  { cols: [formData.cols], rows: formData.groupby }]),
   };
   ```
   
   I'm not sure how to model the query vs dataframe operations, should it be incorporate into the query, or made into its own thing. Clearly on the backend we need two abstractions as one is used to interact with connectors (querying) and the other applies to all connectors (dataframe transformation).
   
   I also wonder whether we could expose most of the pandas API from the frontend by doing a bit of magic, where the `dataframeOperations` above would somehow do something like `getattr(df, command)(**props)` on the backend.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org