-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import/export JSON for models and diagrams #332
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've put this in components
and export in util
because export doesn't actually build a component but it needs to be used by model_menu
, diagram_menu
, and analysis_menu
. Not sure if that's the right file structure.
@@ -48,7 +51,13 @@ export function DiagramMenuItems(props: { | |||
navigate(`/diagram/${newRef}`); | |||
}; | |||
|
|||
return ( | |||
//Can this be less repetitive? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i.e. I'm wondering whether we should have an overarching Menu
type that extends to DiagramMenu
etc. Seems like a fair amount of duplicated boilerplate otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Edit: I took a shot at this, it was less scary than I initially thought. PR is here
old:
Based off of my limited understanding, I feel like we should hold off on merging them.
- The menus are different enough that the abstraction currently would not be much more than an if statement for each menu item, which I don't think is worth the additional complexity.
- We could fix that by defining generic interfaces that work for both models and diagrams (like what you've done for the import), but that's a non-zero amount of work and... - It's not obvious how much similarity there will be between the two menus going forward, and if they keep diverging an abstraction would become increasingly costly to maintain.
An alternative might be to create reusable components for menu items which can be easily shared. In this case it would be something like which add the 2 menu items and there handler.
Composition over inheritance and premature optimization is generally bad
return ( | ||
//Can this be less repetitive? | ||
const onDownloadJSON = (diagram: DiagramDocument) => { | ||
downloadJson({ data: JSON.stringify(diagram), filename: `${diagram.name}.json` }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The straight stringify
of a diagram contains the Automerge hash of the diagram's model. What this means is that this simplest possible implementation has the behavior that if you download a diagram D in model M and then re-upload it, you get a diagram D' in the same model M. I think this is plausible behavior but worth thinking over.
I've added some css for the import menu. I was hoping to make the text box auto-widen after pasting in json but couldn't quite figure out the right way to do this, so it just gets taller at the moment. I suppose it doesn't matter much, people aren't likely to be looking closely at their raw JSON. Possibly the ideal solution would be to have an in-client JSON parser display the pasted JSON nicely formatted? But it seems pretty unimportant. |
const blob = new Blob([jsonString], { type: "application/json" }); | ||
const url = URL.createObjectURL(blob); | ||
|
||
const link = document.createElement("a"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surely there's a less weirdo way to do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not yet unfortunately. We're waiting on the new File System API to land in all browsers, specifically showSaveFilePicker
It is worth noting that some people have security setting such that .click() is not allowed. Nothing will happen for those people. The setting is super rare.
There are other ways of doing this, but on review I think this is still likely the best option.
de67be2
to
d9689fe
Compare
return ( | ||
<MenuItem onSelect={props.showImport}> | ||
<UploadIcon /> | ||
<MenuItemLabel>{"Import notebook"}</MenuItemLabel> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I put this at the very top because I think it should be next to the "new" buttons which are handled by document type and otherwise I'd have to split up the child.props below.
@epatters Ready for your consideration. A couple more questions that remain:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At a high level this looks good! There are a number of nits, I have a PR with fixes for them here
I'm trying to gauge my pickiness off of the cleanliness of the rest of the codebase (very clean!), let me know if you'd like to apply a different amount of rigor.
throw new Error("Please upload a JSON file"); | ||
} | ||
|
||
const MAX_FILE_SIZE = 5 * 1024 * 1024; // 5MB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: you are absolutely going to want to enforce this on the backend as well, and for that it would be best to use the same constant. but that is a later problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added an issue for this. #408
fix review nits for `json_io`
This PR implements the ability to download a JSON dump of a model or a diagram and to upload it back via either the file browser or copy-paste.
A little skeleton code is present for analyses but there are design questions there and I would guess we should just merge this without worrying about analyses yet.
TODO: