mcnuttandrew / prong Goto Github PK

After changing the position of the examples charts in the in-situ example, the old charts are not cleared.

Performance optimization: projection placement takes a long time for largeish specs (eg one containing a whole dataset), make caching fast enough where it can deal with that. See for example the vega-lite "ide" with a bigger input. (A cheat might be to never push that data into the rendering of the program, but have the spreadsheet still be able to show it)

A question during the VLHCC talk was "can prong do yaml?"
The answer right now is no, but there's not an especially strong reason for that. Currently there's a number of connections to JSON, such as via the json parser and some of the typings, that prevent support of YAML. It'd be a big under taking to add but its far from impossible.

• Projection id is not currently type checked (tech debt)
• Projection names are useful, bring them back and add a category field to the tooltip ones
• Tooltip projections should be allowed to provide a notion of view / effect so that they can be selected automatically (that is through the keyboard only interaction)
• Remove full tooltip type

There are a few functionalities that we implement which already exist in jsonc. There's are likely more robust, so it'd be good to explore how we can use their work

Right now its clumsy/awkward, it would be good to make it be better more consistantly

Sometimes the schema is wrong and you know better, enable a means to remove them.
Two approaches seem possible

1. Stateful held in memory: upside "easy" to implement, downside might lead to opaque/negative stuff for the user
2. add modifications to the code itself. bc we are operating over JSONC this could be through magic comments, but that introduces some potential confusion for users

• Validate forbidden properties
• Highlight required properties
• Smarter "valid json" clean up (eg suggest '' -> "" type things)

Basically i want to be able to turn on the debugger without modifying my code substantially

Doesn't look like there's an option to control editor initial docking status or general dockability. I'd rather like this! (Specifically, because I'd like the editor to start docked in my application.) 🙏

Many of the dependancies in the main package come from the standard bundle, so it might be good to push it out to it's own package to reduce the size of the application.

Little tidy code, but for just one area

Currently there are two distinct rendering paths, which makes cache/other optimizations a little tedious

Most of the examples should how to manipulate a single property, it would be useful to to demonstrate how to interact with more than one property.

AND OR, maybe NOT