Update the version of json-editor in the schema editor

[jeancochrane]

The schema editor currently uses an Azavea-maintained fork of Jeremy Dorn's json-editor library. Jeremy Dorn's version of the library has since been deprecated in favor of a community-maintained fork.

We should update the schema editor to use the actively-maintained version of JSON Editor. This work will involve auditing the Azavea fork to see what features we use that aren't in core, and making sure that those changes are included in whatever version we use (whether it means updating the Azavea fork, or trying to get those changes accepted into the core).

[jeancochrane]

I did a quick audit of the changes made by the Azavea json-editor fork. Here's a breakdown of the diff, including information about whether or not features have been incorporated into the community fork (A :x: under "Mission-critical?" means that the feature is important for us):

Change	Implemented in community fork?	Mission-critical?
Title collapsible form sections (source)	:question: (Can't find in code, but it seems to work fine)	:question:
Translate buttons (source)	:heavy_check_mark: (source)
New stylesheet (source)	:x: (Looks fine, however)	:question: (Can't really tell)
Add title to "Expand" buttons (source)	:heavy_check_mark: (source)
Disable row cache for optional fields (source)	:x:	:x:
Separate styling for required fields (source)	:x:	:x:
Do not delete object properties that are empty and non-required (source)	:x:	:x:
Disable immediate input check for related values (source)	:x:	:x:
Null option for non-required select fields (source)	:x:	:x:
When select field options are not required, default to the null option (source)	:x:

In brief: most of these features have not been brought into the codebase.

I can see a few opportunities for PRs into the community fork. Some features that they would probably appreciate:

• Clearer styling for required fields
• Null option for non-required select fields
• When select field options are not required, default to the null (seems to maybe be a part of the codebase...?)

However, the rest of the features are pretty specific to our implementation. This leads me to wonder: what's the best path forward for upgrading? I can see two options:

1. Merge in the current changes from the community fork into the Azavea fork, and continue using the Azavea fork in the schema editor.

   • Pros:
     • Fast and easy
   • Cons:
     • Hard to maintain (we'll eventually want to bring in changes again, but the history of the Azavea fork indicates that the bandwidth isn't really there for this kind of work)

2. Use the community fork in the schema editor instead, and implement local fixes on top of it.

   • Pros:
     • Easier to update
   • Cons:
     • Not entirely clear how to implement local fixes -- would probably require hacky monkeypatches
     • Updates might still be a pain, since the local fixes will be tightly coupled to the json-editor implementation, meaning that updates could introduce difficult-to-locate breaking changes

Is there a better way of thinking about this problem that I'm missing?

[ddohler]

No, I think those two options about sum it up; we've run into this situation before where we wanted to fork a project but also stay updated with upstream. We generally went with approach 1, so I think I'd lean toward that. However, I will say that I think reducing the footprint of the Azavea-specific changes will help to keep maintenance costs low, so it's probably still valuable to make PRs to the community fork wherever possible.