villebro commented on issue #44875:
URL: https://github.com/apache/superset/issues/44875#issuecomment-5999252649
Thanks @michael-s-molina for the comments! My responses below
5.> >
> > 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.
As with other entity types, we need to be able to have performant list views
with full filtering support that scales to 100k+ entries. For this reason
storing widgets as KV entries is not an option. I'll add a note in the SIP.
> > 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.
We discussed this with @msyavuz today, and I think the jury is still out on
the optimal UX for this: I feel we may want to have some form of "commit"
button to group multiple edits together, while Mehmet was gravitating towards
each mutation being persisted with version control. Sync debounce/batching is
also a good idea. For now we can leave this open and fine tune as the feature
starts stabilizing.
> > 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.
Sounds reasonable 👍
> > 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.
I agree on this. Once we get to this point on the feature branch I think it
will become more clear what the correct design should be.
> > 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.
I would push back here. While a generic ECharts widget is a great escape
hatch for leveraging the full functionality of ECharts (or any other similar
swiss army knife viz library), its schema has evolved over time, and is really
a massive union of typed very varied sub-schemas. So expressing this EChart
option "omnischema" as a renderable control panel would be very challenging.
And even if we do go with a single code block "option" control (which is what I
propose), it will often times require reinventing the wheel for typical chart
types, legends, labels, axes, theming etc often require extensive customization
to have good look and feel. So I still feel there's a place for these simple
specialized viz-types.
--
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]
