hvega icon indicating copy to clipboard operation
hvega copied to clipboard

Expose everything

Open mpickering opened this issue 5 years ago • 4 comments

I needed to use the window transform and because the library doesn't support it I had to fall back to writing some inline JSON. This is expected but then integrating the inline JSON into the AST was quite hard. One particular point is VLProperty does not export its constructors so I have to call transform [] in order to get a VLTransform constructor. It also wasn't easy to combine together the new window json with calculateAt and filter. I ended up writing the whole block manually.

In my opinion it would be better to expose everything so that users can work around missing parts of the library more easily.

mpickering avatar Jun 18 '19 11:06 mpickering

I also found "inserting" (or transforming) the specification to add missing functionality was not as easy as I'd have liked, but I can't remember the reason why (if it was just missing exports or some other reason).

DougBurke avatar Jun 22 '19 21:06 DougBurke

I am reluctant to just expose everything because the internals of the module are not really designed for public consumption, and would add a lot of new symbols which would confuse the user - i.e. there's not really a clean break between "this is to create the visualization (user)" and "this is to convert the visualization into JSON (library)". Perhaps the latter functions and data types could be moved into an "Internal" module which would make things a bit clearer.

Is there a slightly-more principled approach that could be useful? What are the use cases? For example, I can think of (but I'm sure not complete):

  • I want to change the schema being used
  • there's a bug in the current serialization that I want to fix
  • there's a property/value that is missing from the API
  • something has been added to the schema since the module was created (could be as simple as a new property, or something more complex) that I want to use

Is there a way to support these without exposing everything, or is that just a pipe dream?

DougBurke avatar Jul 02 '19 02:07 DougBurke

@DougBurke It is too unpredictable to know where there will be bug or a new feature which is not supported.

I think the only reasonable solution is to move all the definitions into an Internal module and reexport what you consider to be the public API from a different module.

mpickering avatar Jul 02 '19 07:07 mpickering

#85 makes it easier to change the Vega-Lite schema being used.

DougBurke avatar Aug 22 '19 16:08 DougBurke