hvega
hvega copied to clipboard
Expose everything
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.
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).
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 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.
#85 makes it easier to change the Vega-Lite schema being used.