Planning for V2

[CarlosNZ]

I'm looking at building V2 of this component in the next wee while, so keen to get some user feedback before I dig into it, mainly around the workflow and syntax. Here's a few things I think would be good to change for V2, so please let me know your thoughts on them, or any other suggestions.

(Note, I'm not particularly looking for "feature requests" (make an issue for those), more improvements to the current functionality to make it easier to use or more logical)

• I think I've got the "restrict" props backwards, in that you put true to disallow editing, and false to allow it. Thinking of changing the name from restrictEdit to allowEdit, where a true result means you can do the edit.
• Thinking of removing the themes from the published package and putting them into their own package (along with a few custom components)
• Consistency in the terminology between "custom components" and "custom nodes", they're the same thing, so which name makes more sense?
• Add an isValid property to each node, which can be set via Update functions. This would allow you to show an "error" in the UI when invalid values are entered, as opposed to now when invalid values would either have to simply be rejected or accepted.
• More sensible return type for Update Functions -- this changed incrementally, so had to fudge it a bit to avoid breaking current functionality. In my view the return values should be:
  • true | void | undefined => proceed with the update
  • false => don't update (displays generic error message)
  • { value?: <some value>, isValid?: <bool>, error?: <error message> } => Use "value" as the updated data, display "error" as message (can use either one, or both of these), "isValid" sets internal isValid state, which would display a different kind of warning.
• Export a JsonViewer component -- this would be exactly the same as JsonEditor except all the editing capabilities will be disabled (same as passing viewOnly to JsonEditor)
• Performance-wise, I'd like to be able to update individual nodes without causing a re-render of the entire tree, as this makes updates a bit slow with very large data sets. I have some thoughts as to how this might work, but open to suggestions.

[CarlosNZ]

Other features that have been requested that will need to wait for v2:

• Provide a distinct onRenameProperty callback when keys are renamed, as opposed to just calling onEdit link