michael-s-molina commented on issue #44875:
URL: https://github.com/apache/superset/issues/44875#issuecomment-5994249150
Thank you for the SIP @villebro! Initial suggestions:
<br>
> 2. Defining a widget: the widget contract
Love the pseudo backend representation of widgets! The annotated approach is
perfectly aligned with other core entities 👍🏼
<br>
> 5. Storing instances: persisted, inline and placed
Here it might be interesting to think about and add to the SIP the
relationship between the widgets table and the extensions storage table. If we
intend to have a specific widget table, let's just explain why.
<br>
> 6. Editing instances: drafts and validation
It might be worth calling out that edit syncs can be delayed and batched to
avoid roundtrips for every change.
<br>
> 7. Querying: QueryMixin and SemanticQuery
> A chart turns an instance's props into queries on the backend. Authors see
one query format, SemanticQuery from the Semantic Layer work (SIP-182): a
small, typed model of metrics, dimensions, filters, order, limit and group
limit, onto which the core composite controls map one-to-one.
Yes! Having a single query format is very important! @betodealmeida will
love this.
<br>
> 8. Delivering data: access by widget instance
Maybe use `/api/v1/widgets/{uuid}/data` or
`/api/v1/widgets/instance/{uuid}/data` instead of
`/api/v1/widget_instance/{uuid}/data`? It seems the UUID already gives you the
instance abstraction so the first suggestion would be good.
<br>
> 9. Reacting to filters: the interactivity contract
I think it's important to make it more clear that the event bus behind
widgets is generic, it accepts any type of event. You can have typed hooks like
`useRuntimeFilters` or `emitFilter` but ideally they use the generic bus behind
the scenes. This point is important because widgets can be extended and we
don't know what type of events they fire. `dashboard-v2` prototype has this
generic event bus concept.
<br>
> 11. A special case: the templated ECharts widget
> The widgets described so far are standard widgets: every property is
declared in the schema, so the property panel covers everything and validation
is complete. That is the right default, but no set of standard widgets will
ever cover every visualization people want.
I think is very important to keep a single component for ECharts. Ideally,
if we want to restrict the number of properties displayed, that would just be a
predefined schema on top of ECharts options but not different components as we
have now.
--
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]
