Overhaul and extra maintenance help?

[thclark]

Hi @nnseva,

I'm from @octue - we're an open-source organisation whose mission is to help scientists and engineers work more effectively with data - we maintain libraries like django-gcp for example.

We're doing quite a lot of work with managing JSON documents in django, and need greatly improved capability in the admin panels. We're currently using this package but looking to do a significant update - essentially we're facing a total re-write from the ground up:

• to use the newer, more performant svelte-jsoneditor library (now that jos de jong has deprecated the ACE editor)
• to add compatibility with the django-unfold admin (eg using tailwind's variables for colouring and selection of light/dark mode and using htmx/alpine rather than jQuery).
• add a testing framework with additional documentation and examples.
• add a CI system and automated release process
• remove backward compatibility for older fields (stick to the django inbuilt jsonfield)

I hate it when the OSS community goes "oh it's a big change, I'll just make another library" - it leads to fragmentation in the ecosystem. We could do all this then release as an entirely new library. But before we do, I wanted to check in with you and see if you're open to the idea of us helping to overhaul this library with a significant breaking change (or even whether you're jaded with the maintenance and would prefer to hand it over entirely).

What are your thoughts?

Tom Clark (Founder @octue)

[nnseva]

Hi @thclark,

I am glad to see your interest in improving the library.

I know that many people use this package and need to have backward compatibility. I am afraid, that an immediate move to the new JS library may break some custom code extensions created by users of this package. Such extensions are totally out of the control of the package and use direct calls to the JS library, so they are dependent on the JS library's own structure and internals. We high probably never cover all cases of such customization, so the backward compatibility will be fully available only restricting the package version.

We could create a branch, say v2.0, declare the original branch as deprecated, and support both lines together for some time, having backward compatibility as long as possible.

But.

As you see, the code of the package is very poor. It mostly adopts the JS library and provides some customization hooks, to avoid direct changes in the source code when providing customized features. So the question is, whether we really need such complex steps to adopt this poor code. What would be a difference between this way, when we have django-jsoneditor<2.0 and django-jsoneditor>=2.0, and a way with totally separate libraries, django-jsoneditor and let's say, django-svelte-jsoneditor?

In order to control versions, I could (if GitHub allows that) create a branch v2.0 and make you an owner of this branch. Also, I probably should share the PyPi repository django-jsoneditor, to allow you to upload new versions of the library to the public domain. But what would be the difference between this way, and having totally separate GitHub and PyPi repositories for django-jsonfield and django-svetle-jsonfield? Moreover, on the way proposed by you, newly released versions >=2.0 will lead to user issues, and I should explain to every one of them - yes, the new version is incompatible, so either adapt your code to the new version or restrict the version like <2.0.

Based on the fact that the jsoneditor original JS library yet exists, although probably is deprecated in favor of the svetle-jsoneditor, but not replaced by it, I am ready to add a link to your new library to my repository, when your library is ready for release. As an answer, I would be glad to see the backlink from your library's documentation to my one, in the chapter like Inspired by, or The code based on.

Sincerey,
Vsevolod Novikov

PS: you cannot totally avoid using jQuery, because the Django itself uses it in many places. As you see, I am not using a new link to the jQuery, but using the original Django-loaded jQuery instance.

PPS: When I tried to create some testing code, I really stopped on the question to myself, what the case could really be tested? I am afraid that the test code should use some kind of the browser emulator to check the real view of the page.

[thclark]

Hi Vsevolod - thanks for getting back to me!

Hmm, yes it creates a difficult situation that some users of this package are also hooking directly to the ace editor JS library. I hadn't appreciated that. What we would do is a breaking change anyway, but it'd be a severely breaking change for that set of users.

Yes, we could support both lines at once on different branches. But, it would create problems in the event that you needed to create a (less severe) breaking change on the original version - you'd have nowhere to go with the version numbering.

Also, thinking about it, Jos deJong didn't make a major version change to the ace editor, he started an entirely separate project and so perhaps there's merit in mirroring that.

So let's start off in separate libraries, but stay in touch and think about whether there's a case for merging the projects down the road - I appreciate the willingness to put up a link, too - we'll let you know when we've reached a stable release!

You can watch us evolve over here and please do let me know if you'd like to participate in the maintenance of that library.

On jQuery - noted, thanks.

On testing - yes, I'm afraid it'll mostly just be the basics of whether a template will render or not. Minimal stuff but better than nothing :)