Continued from the discussion in [SIP-5] #5680
There is a decent amount of work to be done to make the visualization plugins
are truly independent from the core superset.
### Q1: What need to be converted to JS?
> @mistercrunch : 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 front-end (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.
### Q2: Where these new front-end methods should live?
> @mistercrunch : 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 = {
// Adapter from [SIP-5]
adaptor,
// Convert formData into queryable format
queryGenerator: (formData) => generateQuery(formData),
// Convert formData into post-query operations
dataframeOperations: (formData) => (
['pivot_table', { cols: [formData.cols], rows: formData.groupby }]
),
};
```
### Q3: How to actually implement these two parts?
> @mistercrunch : 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).
> @john-bodley : I'm also perplexed as to how to best generalize this. It seems
> a first step is to map arbitrary data (via a query) into a somewhat generic
> (potentially visualization aware) form.
> @mistercrunch : 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.
[ Full content available at:
https://github.com/apache/incubator-superset/issues/5692 ]
This message was relayed via gitbox.apache.org for [email protected]
