Is it possible to manually render <perspective-expression-editor>?

[jkusa]

I am looking to see if I can manually render <perspective-expression-editor> (with all the column and ExprTK suggestions) outside of the <perspective-viewer>. Ultimately, I am interested in capturing the user's input from the editor and then manually adding the expression to the perspective config. Is this at all possible or supported?

Thanks!

[texodus]

It's not currently possible, the custom element itself is separate but internally it is deeply intertwined with the <perspective-viewer> state. Can you describe in more detail what you're trying to achieve at a UX level? We could potentially add this, but if there is an opportunity to make the <perspective-viewer> experience better, I would much prefer we put development time into that, instead of refactoring the code to a collection of interoperable widgets.

[jkusa]

Hey @texodus 👋 Thanks for the quick reply.

I recently discovered Perspective (which is awesome btw) and think it could be a great fit for an open source reporting framework I help maintain called Yavin. Both Perspective's visualizations and expression engine could be a great addition. 

Regarding the UX, Yavin already has a column selector/editor to build analytic queries that are sent to our backend. Ideally, we would present a single column experience to the user, instead of one for query building and one for Perspective configuration. 

I think we would be able to replicate the "group by", "split by", etc controls in our UI flow, but replicating the <perspective-expression-editor> with all the assistance would be non-trivial.

It would be great if we could trigger the <perspective-expression-editor> from our column editor and have it render near a specific selector.

[texodus]

No, this is most certainly out-of-scope for perspective. The open source libraries Perspective's charting, datagrid, expression editor and evaluation engine are built with already have excellent, fully extensible APIs of their own - D3FC, regular-table, monaco-editor and ExprTK respectively.

[jkusa]

Got it.

Yeah, the underlying technologies do provide extensible APIs, Perspective just wires them up nicely with data APIs, a config format, and framework for adding additional visualizations. But, I get it, if exposing <perspective-expression-editor> as a first class component is a pain (especially if it wasn't designed that way).

To your point about existing APIs, I recently found this example that demonstrates sharing a single monaco instance with the support for the custom exprtk language and theme. Instead of rendering <perspective-expression-editor>, one might be able to achieve a similar experience with rendering a <MonacoEditor> component. Although, if the language registration is lazy loaded, it might not be that simple.

Thanks for your time chatting about this 🙏

[jkusa]

Although, if the language registration is lazy loaded, it might not be that simple.

After setting up the react-monaco example locally, it looks that this is true. Only after I clicked "Add Column", exprtk language support was available in the <ConfigEditor> on the left.