Comments (7)
@farmaazon i mean an optional parameter on to_json - i can imagine people wanting to explicitly have to_json in their graph
from enso.
i think approach 1 is cleaner from an API point of view, but i think we should be going for approach 2 because things should Just Work for an end user. we can always figure out an API to communicate to the GUI what the actual expression is for getting that specific property.
from enso.
The GUI technically has the type information to make this distinction already, but I think rather than use that it would be a cleaner solution for the visualization to return information about how to access fields alongside the data; this would also generalize better toward what you're suggesting, @somebody1234 --- that sounds really cool and would make the JSON viz a general interface for exploring typed structured data.
Right now the viz just returns the raw JSON; we would need something like:
interface JsonVizData {
/** JSON */
data: unknown,
/** If provided, when creating accessors, a method with this name will be called first (this would probably always be `to_js_object`). */
to_json: string | null
}
Of course if we implement type-specific getters in the future this would replace the to_json
property.
from enso.
The GUI technically has the type information to make this distinction already, but I think rather than use that it would be a cleaner solution for the visualization to return information about how to access fields alongside the data; this would also generalize better toward what you're suggesting, @somebody1234 --- that sounds really cool and would make the JSON viz a general interface for exploring typed structured data.
Right now the viz just returns the raw JSON; we would need something like:
interface JsonVizData { /** JSON */ data: unknown, /** If provided, when creating accessors, a method with this name will be called first (this would probably always be `to_js_object`). */ to_json: string | null }Of course if we implement type-specific getters in the future this would replace the
to_json
property.
This is nice, but I think if we want to go down this path, it may make sense to make it even more generic.
For example, for the case I showed in the ticket with the Date
type, when I click on year
now I get my_node.get "year"
which does not work. With your proposal I'd get my_node.to_js_object.get "year"
which works so it is better, but it is a bit going around. Ideally, it should do just my_node.year
which is the 'preferred' way to access this field.
To implement that, maybe we need to define some way on the type to declare how to access each of the properties, i.e. a function taking the name of the property and returning a 'code template' to get it. We could probably rely on Meta
to implement a generic way that will work for most objects, with the exception of special handling for some (e.g. JS_Object
, maybe Map
etc.).
from enso.
I would think that information would need to be provided as part of the to_json
API, since that's where the mapping between fields and JSON fields is established. Anyway, whether we will take the JsonVizData
baby step or go directly to a protocol for specifying type-specific getters, the GUI needs more than the raw data from the visualization.
from enso.
fwiw i'm not sure about providing it in to_json
itself - remember, this language also has a textual format, and to_json
is the intuitive way imo to generate a json to output into a file.
i think it'd be a better idea to have a separate, related method - something like to_json_with_metadata
(an optional parameter to to_json
would work but i think it would clutter up the graph editor when the method is shown). it should probably also be marked as internal or something, so it doesn't show up in the Component Browser as well
(edit: note that the above assumes we do end up going the to_json
(or similar) route, of course)
from enso.
i think it'd be a better idea to have a separate, related method - something like
to_json_with_metadata
(an optional parameter toto_json
would work but i think it would clutter up the graph editor when the method is shown). it should probably also be marked as internal or something, so it doesn't show up in the Component Browser as well
It won't clutter the Graph Editor, as it will be called as visualization preprocessor, and the returned information should be handled by visualization itself.
from enso.
Related Issues (20)
- Add hand to drag cursor (part 2) HOT 1
- Cloud Integrated File Browser
- Sliders display 0 when there is no default value HOT 2
- Opening a ensoproject file bug
- New find_duplicates component HOT 1
- Partially applied autoscope constructors get thru ascribed type check
- Remove expression UUIDs from metadata section of a source file HOT 3
- The project name is always accepted, regardless which button I click. HOT 2
- Filter component's drop down bugs
- Autoscoping can build `ClosureRootNode` with a `null` `ModuleScope`
- Stopping a (local) project results in a crash HOT 1
- Output port interaction hint HOT 1
- Migrate to pnpm
- Migrate to pnpm
- StackOverflow when multiple Managed Resources are being cleaned up at the same time HOT 3
- Benchmark results website 2.0 HOT 1
- Read `Decimal` column from Postgres into in-memory table HOT 1
- Optimize Windows-1252 fallback logic in `Encoding.Default` to do only one pass on the happy path
- cannot login on mac app HOT 1
- `Meta.get_qualified_type_name` does not work when run outside of project
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from enso.