Proposal: Deprecate this repository

[jpdriver]

If you're already using this library, you've probably noticed that there are a lot of open issues and PR's that are going un-adressed and ignored.

The only PRs that actually get merged in are the ones that Adazzle internally decides directly benefit their own business needs.

There aren't any outside maintainers (I don't actually work there), as Adazzle's parent company expressly forbids granting these privileges to anyone not on staff.

---

This is not open source.

It isn't a collaborative effort to build what should be the best data grid library for React applications.

The build isn't even stable -- it breaks from one "minor" version to the next, contains a myriad of bugs and anti-patterns, is confusing to new users, etc.

I can't in good conscience recommend that anyone use this library in a production environment anymore, given the state it's in and the way it's "maintained".

---

So here's what I propose.

We deprecate this repository.

We move it outside Adazzle, and start working on it properly, as a truly open-source library.

This would be similar to how Facebook eventually stopped maintaining Fixed Data Table, and the outside community took it over and continued it as Fixed Data Table 2.

This is something that I've been thinking about for a long time and I just keep coming back to the same thing.

Adazzle themselves could also switch over to the new repository without any business impact, and it would also completely remove their "maintenance" burden so they could focus on their internal priorities.

Freeing up the project from Adazzle will let anyone who wants to take an active role in maintaining it get fully involved. It will absolutely result in a better, more stable library -- which would benefit everyone equally, Adazzle included.

Put simply -- I can't think of any reason not to do it.

---

Potential next steps

The ideal solution would be for Adazzle to fully transfer this repository to a truly open-source organisation. That way, all the existing issues and PRs come along with it.

As mentioned above, they may or may not be able / willing to do that -- so failing that I'd propose using Google's Github Issue Mover tool to copy the Issues across and close the original ones. This repository should then be marked as Archived and read-only.

And failing all of that -- this project is MIT licensed so let's just do it anyway.

I've grabbed the GH organisation and forked it here

[nevace]

I'm game. I ended up using a local copy and fixing issues myself because PRs have been ignored forever. If we can get these PRs in then a lot of people can go back to using it as a library and there won't be so many forks.

[Salt7900]

I too would be willing to jump in... I use this a lot for various projects and would like to see active development on it as well.

[lord-xeon]

I would support this decision wholeheartedly. How long are we going to give adazzle before we decide on a way forward.

Additionally, who/what/how will this be published to npm?

[biggest-dave]

I'm up for helping also. Been hacking this library too long.

[jason-henriksen]

I'm on board. Just this last weekend I was about ready to write my own docs for this package for internal use. The only thing holding me back was knowing that adazzle would never accept the pull request of my work.

count me in!

[jpdriver]

great to see some positive responses and encouragement on this thread. so we don't pollute this issue too much, let's move future discussions to Issues on the new repo.

just for clarity or anyone finding this issue in future, the intent behind migrating to a new repository isn't to exclude Adazzle from future development at all.

this is about opening up responsibility to a wider circle, and granting maintainer status to anyone who wants to get involved.

that permission should always be available equally; and i hope you'll join me in welcoming the original maintainers if and when they get involved.

[jpdriver]

@lord-xeon we'll re-publish the packages on NPM under a new @react-data-grid organisation so it matches the new GitHub one.

[malonecj]

We understand the frustration. Unfortunately, we have not been able to provide adequate resources to maintain the repository in the way that we wish. Also, as this is widely used internally, we cannot currently grant outside maintainers to merge pull requests of their own.

This does not mean that we don't intend to maintain the repo going forward, and make a better effort than we have been. We are meeting to review how we can better maintain it internally. If you feel, that it would be better to fork, and grant a maintainer status to anyone, then please do so. We politely ask however that you choose another name for the forked repository and give credit back to this one, as well as the original repo by Prometheus Research.

[milesrichardson]

+1

This (was) a great repository, and I haven't found anything similar with all the same features. However it has continuously decayed to the point that I'm hesitant to even include it in projects.

The most nagging issue for me is the warning spam (#978) and the fact that it means I cannot upgrade my app to React 16. Please, please, please somebody fix this.

I'm all for the fork and would be happy to contribute myself.

[milesrichardson]

I have to say, it's a little confusing why adazzle would hamper development of an ostensibly open source repo just because their internal tools depend on it. Wouldn't it make more sense for adazzle to fork the repo for its internal use, and then accept PRs to this one? Or even just maintain a separate branch for adazzle only features. But it makes no sense to halt development on a repo and deny PRs because it will break your internal code. There are solutions to this already -- branches, versions, forks, etc... How would adazzle handle this if the project was from another organization and they could not control the changes?

[jpdriver]

it's important to understand Adazzle's restricted position here -- not adding external maintainers comes from their parent company; so even if they wanted to open this repository up their hands are tied.

as I understand it though, that restriction is around adding external contributors to internal projects.

presumably it doesn't say anything about internal developers using or contributing to external projects
-- otherwise I don't know how you're building a JavaScript platform in 2017.

---

to reiterate @malonecj -- you and any other internal maintainers are more than welcome to full admin rights on the new project if you want them.

that should give you a 1:1 match with this repository -- but the difference would be that as a collective community we could move faster, fix more bugs, and introduce new features.

---

we like this project. we really want to use it. and there's very little out there like it.

but as long as you're forcing the community to relinquish their ability to get involved as contributors or maintainers, there will be an appetite for a truly open source version of this project.

[jrnail23]

I'm all for splitting this out into a new repo. Just one thing, though. I'd really like to see some transparency in the direction and planning (i.e., a roadmap and RFCs for new ideas).

[malonecj]

Closing this for now. It seems like there are quite a few people who will be happy to move to a forked repo. To all those I wish you good luck.
I can't promise that there will be overnight changes with the managing of this repository but we will do a much better job than managing it than we have been. Check back in here in a few weeks and we will see

[TimNZ]

@jpdriver looks like nothing came out of this?

[jason-henriksen]

@TimNZ : I worked with JP on this initially. The first effort did not come together.

However, from that effort I've started a rewrite project at

react-json-grid

It's ALMOST BUT NOT QUITE done.

You can see how far I've gotten at:
https://react-json-grid.azurewebsites.net/

Github is here:
https://github.com/jason-henriksen/react-json-grid

After doing git you can test with:
npm run storybook

It can be installed via NPM and it does have a large suite of storybook tests.
npm install react-json-grid

I've tested this and the npm deployed component does work in other ES6 apps (for me).

Features That are Working:

• interactive, edit by default data handling
• interactive documentation / API playground
• can handle data in it's original format ( array of objects, array of arrays or array of primitives)
• very simply API
• add/remove row support
• pivot support
• style by style object
• style by class names
• built in checkboxes, date selection, menu select, 2 money formats and validation editing
• Written in ES6, and runs without errors on react 16
• Text Mode edit support
• Most keyboard navigation supported

Not yet done (but planned soon!):

• using your own components in cells and editors (so close, but not there yet)
• finish keyboard navigation support
• API playground is very close but needs more polish
• Migration guide for moving from RDG to RJG. (Possibly even an API bridge)
• native support for CSV/PSV/KVP data. (The grid goal is to handle any tabular data as is)
• deploy size optimization. (right now we're just making it correct. Then we will make it small.)

Please give it a try and kick it around to see what you think!
I am very open to PRs and general ideas and I intend to actively maintain this grid component for basically ever. (I use a lot of grids in my work)

I hope you like it!

• Jason

[TimNZ]

@jason-henriksen cool.

I will keep an eye on it.

[Se0ng11]

Sad to see a great react grid just gone like this

[jason-henriksen]

Please take a look at react-json-grid. It is mostly done.

I really need some feedback on that tool. If people like it's direction, I will build a migration guide on how to migrate from react-data-grid to react-json-grid.