Revises Markdown Pages and Reports

[guerler]

Very early draft, sketching out and exploring how Vega and other Visualizations can be added to our Markdown components. There is still a lot to do, particularly with regard to early preview, parameter replacement, tests, modularity, element resizing etc. The report/page editor requires a significant overhaul and there are many issues to be fixed, so no need for a review as of right now.

Screen.Recording.2025-02-08.at.3.26.31.PM.mov

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[jmchilton]

I suspect this is going in a different direction but I want to reiterate points I failed to make with workflow comments but that I think are important. We've been around for 20 years - twice as long as vega - we should assume these blobs will be in databases in 2044 IMO - we shouldn't be tied to particular JavaScript library choices and we should look at this from a language design and maintenance perspective. We should develop a syntax for the charts we want to support and have a compatibility layer.

```galaxy
bar_chart(history_dataset_id=X, columns=[1,3])
```

There should be a testing framework that rapidly demonstrates all the charts so we can visually diff things and render them on the frontend or backend with different technologies. The goal should be sustainable, maintainable set of components and not exposing every feature of vega lite.

Even if the syntax is exactly vega lite's syntax - which is totally fine and makes a lot of sense - I think we should validate it is a very strict subset we are confident could be rendered using some other technology (native D3, ggplot, plotnine, etc...).

[guerler]

@jmchilton Thank you for your feedback! I see your point about long-term sustainability and avoiding dependencies on specific JavaScript libraries. Defining a clear syntax and ensuring compatibility with multiple rendering technologies makes a lot of sense, especially for maintainability over the next couple of decades.

I totally agree that we can and should provide visualizations as you described—ones that we fully control and that render both on the backend and frontend. This would give us a sustainable and maintainable set of components. However, we can’t take this approach for all visualizations, particularly for things like Vitessce, Protein Viewers or Plotly, where we rely on third-party solutions. Also, our new visualization framework is far superior since visualizations are fully prepackaged and self-contained, without relying on Galaxy internals, making them more robust, testable and maintainable than in the past.

Given that, perhaps the best approach is to make it optional—allowing admins, and possibly even users, to decide whether they want to integrate third-party visualizations from our new plugin framework or stick with our built-in solutions. This way, we maintain flexibility while ensuring long-term maintainability. Maybe I should add a config flag for this?