zdog
zdog copied to clipboard
Save/load graph JSON
#35 seemed like a fairly simple implementation, so I decided to take a crack at it.
I understand that you may have different plans for this feature, but I figured this would open up a conversation about the possible implementation.
Features
- Adds serialization via a
toJSON
method onAnchor
andVector
. This is natively called byJSON.stringify
, soJSON.stringify
ing an illustration will work as expected. - Adds serialization util via
Zdog.exportGraph
. It's really just callingJSON.parse(JSON.stringify(model))
but could be hand-rolled if you want. - Adds a
type
property to each Zdog primitive. There may be a cleaner way to do this, but the JSON needs to store the primitive type as a string so that it can be rehydrated. - Adds
importGraph
option toAnchor
object. Users can pass in- A JSON object generated by
Zdog.exportGraph
- A
string
specifying a relative or absolute path to ajson
file. This seemed like a cool feature which would allow people to easily share models via url. It's just a simplefetch
call for modern browsers, but I realize that this may introduce some unwanted overhead for legacy browsers.
- A JSON object generated by
In Progress
- Code style (Need to double check for consistency)
- Versioning? What happens if Zdog's JSON format changes in the future as new features are added?
- Compression. JSON result is fairly verbose, although I made sure to trim down what I could (single-magnitude vectors to numbers, default options not included, etc). I'm sure there are some interesting ways to optimize the output.
Whoa! Thanks for taking a shot at this. This PR is pretty impressive, as it implements the feature without adding too much bloat. Nice work!
A couple notes
- I'd like to have IE11 support for Zdog v1. Let's remove
fetch
for now. - You can check code style with
npm install
andmake lint
Some blue-sky thinking: what if Zdog's save/load file structure was built out of SVG instead of JSON? I like SVG as it outputs a visual file that users can easily view. I don't this SVG is appropriate for saving/loading data as an SVG file as it would require building a parser and duplicating data in the file source code (like for path data). I'm spitballing here... what if the file was .svg, but it had the JSON embedded in a hidden node. So users sees a 'thumbnail' in the SVG, but the real data is in the JSON within the file? Maybe that's for a future feature.
Thanks! I've removed fetch
and am working through some lint
errors.
The SVG idea is very cool—I will have to play around with it! Off the top of my head, I think the JSON could probably be stringified and embedded as a [data-zdog]
attribute on the root svg
? JSON is probably the most straightforward solution for the time being, though.
Re-thinking this: SVG filetype save/load can be a future feature. It still relies on JSON save/load so that should be the focus.
Also: I think this feature would be better served as a plugin. I think you should build it out directly in Zdog for now, but I'll likely break it out into its own package when its ready for prime time.
I agree that it makes sense for this to be a plugin/extension, but for the sake of making it easy to implement, could we add just the Class.type = 'Class'
metadata? Otherwise it's not straightforward to get the subclass names. This is because of the getSubclass(...)
implementation, as shape.constructor.name
is 'Item'
for all subclasses.
In terms of using the svg as the saved format, I think it makes more sense for saving the 2D representation, as it doesn't inherently have the 3D information in it (neither does the canvas but you could save a 2D picture from it).