Best way to contribute

[derekperkins]

@tannerlinsley and I are looking at completely buying in to mosaic. We've been talking about these ideas for years, and this is the first project that gets all the abstraction points right. I'm a maintainer at Vitess (distributed MySQL), and Tanner has 100k+ GitHub stars between his various projects. We've built OSS table components, heavily contributed to the v2 rewrite of Chart.js, and wrote React Charts trying to figure out how to build dynamic reports for TB scale data.

We know it's still early days for mosaic, where there's still high churn in core components, so we don't want to get in the way. As we've been evaluating it, I think there are a few places where we can add value quickly:

• improve UI component integrations (Improved Documentation for Building Clients #394)
  For this specifically, looking to build some framework agnostic headless components, with some integrations into common UI components like tables and select boxes
• help with SQL translations (Support Databases other than DuckDB #399)

Are there ways we can contribute that will be the most useful? Are there things you'd like us to keep in mind?

Thanks for the fantastic library!

[jheer]

Thanks for reaching out! As a first step, sharing of your experiences and recommendations for improvement is very helpful.

As you build custom components, being able to point to those examples could be helpful for others--either to use them directly or learn from them. And depending on how things go, we could consider ways to better integrate such components into this project's higher level APIs.

In terms of SQL translation, a natural first step would be an audit of DuckDB-specific query constructs. Then there is a question of how to best support multi-DB use.

• One vector is through DuckDB itself, which can query MySQL, Postgres, and SQLite directly. Some folks are already exploring this and may provide helpful documentation. Looking ahead, I'm not sure what the DuckDB roadmap is (or how custom hard extensions would be) to interface to additional DBs.
• If we want to "translate" SQL and standardize around DuckDB's dialect, one could take advantage of DuckDB's SQL-to-JSON parsing as a first step for translation to other DBs.

Please let us know how it goes if you end up pushing in this direction!

[derekperkins]

@jheer Sorry for the delay in responding, we had a few fire to put out. We're diving back in, and this is high priority for us, so I hope to make quick progress. I think the plan is to iterate on UI components and figuring out data interactivity, and then once we're solid on those patterns, we'll move to server implementations.