Frontend hardcoded and send codes to Visualization server, it should be refactoryed

[rmgogogo]

cb4f4ba#diff-3403c794353f09e8d1cde18b6bfc3baa

Python codes should be keep inside Visualization server. Frontend should not hardcode python codes. Aka, if CUSTOM visualization means put python codes in frontend, better we disable it and use TYPED visualization.

[rmgogogo]

@jingzhang36
@Bobgy

[Bobgy]

It's a good point, we should do this. just that I don't feel this is a p0.

This is an example of how to do this: https://github.com/kubeflow/pipelines/pull/3089/files

[eterna2]

Hey guys, what is ur opinion of using Vega as the main vis dsl? I am a big fan of Vega as I think it is a very good dsl for describing vis.

[eterna2]

And I can implement a purely client-side solution. And all it needs is a json spec of the vis.

[Bobgy]

@eterna2 Thanks for offering the idea, current KFP visualization work focuses on integrating existing jupyter notebook visualizations into KFP UI.

For Vega, sounds like an interesting usage, but I don't have much personal experience, can you open a separate issue to discuss about it? Do we expect data scientists using Vega for visualizations directly?

[Ark-kun]

If possible, can we refactor visualization to move the visualization codes to /components/visualizations/<data type>/?
We could have them as proper components that receive the data or URI and output HTML or Markdown.

[Bobgy]

@Ark-kun thanks! that's a good idea to me. Current visualization doesn't take any parameters, sounds like it would be better as components instead. The caching problem is also solved.

[eterna2]

hey I created a issue to describe more on my idea #3187

I don't think vega will solve the issue with existing integration with jupyter notebook vis (unless they are using py lib like https://altair-viz.github.io/ ).

But I think it is very useful moving forward, for more general use cases (i.e. data that do not have a handy lib to generate the vis) and for ml-pipelines-ui-metadata.json

• it is language agnostic and fully client-side

• the dsl makes it easy to provide flexibility to generate any vis on demand, or wrap around a few signals for users to customize the vis

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had recent activity. Please comment "/reopen" to reopen it.