Question about this project future

[trsh]

Issue type

I'm submitting a (check one):
[ ] Bug report
[ ] Feature request
[ ] Regression (something that used to work, but stopped working in a newer version)
[ x] Support request
[ ] Documentation issue or request

@dschnelldavis any plans to continue work on this project. Or it's abandoned?

[cruizba]

+1

I am a bit confused with the future of this lib too @trsh. It's an amazing tool but i see like 3 or 4 forks and i don't know what will be the official one.

These are all the forks i see that probably will continue but i don't know:

Angular6-json-schema-form
ng-json-schema-form
ngx-json-schema

Maybe @dschnelldavis or the creators of this forks (@hamzahamidi , @shamoons or @catull) know something.

[hamzahamidi]

We're using this library in our applications & just recently we updated some of them to Angular v6 which caused a build failure thus the creation of Angular6-json-schema-form which is compatible with AOT.

[j2L4e]

There's also this fork https://github.com/rhalff/angular2-json-schema-form/tree/angular-6 by @rhalff. I'd love to see everyone having a working fork join efforts

[catull]

I have two points to criticize.

1. The name, it focuses on Angular 6 support exclusively.
   Angular 6 is going to be "victim" of its own cadence.
   Twice a year, Angular Team releases a new major release.
   Thus next year the main version is 8.x.
   Imagine you are going to grow the project, and add support for version 7, 8, 9 etc.
   Will you crank out new projects named AngularN-json-schema-form ?
   I would miss continuity or a bigger plan ...

2. Your "fork" completely cuts its tie to the original repo.
   It gives the impression that it is 100% your own work.
   Simply stating its origin in an issue is not enough.

Both points are a deal breaker for me.

[j2L4e]

The name should indeed be ngx-json-schema-form

re your second point:

the readme states Note: This project is a continuation to dschnelldavis/Angular2-json-schema-form & is and is not affiliated with any organization in the very first line. I don't see @hamzahamidi taking credit here.
it should be easy to rebase the changes onto a proper fork, though.

---

re needed refactoring:

• core functionality should focus on properly formatted JSON-schema and compatibility modes should be split off into adapters if possible. The compat stuff is responsible for quite a lot of the clutter in the large functions and is a nightmare to maintain.

• The API should provide FormGroup/Array/Control generation and layout/component generation as separate parts.

---

version support:

I'd imagine the refactoring to take some time, so focussing on 6+ for now seems reasonable to me.

---

Thanks everyone for driving this forward!

[trsh]

I do not get the conclusion of this discussion :(

[trsh]

@dschnelldavis with all respect, I do not know what going an in your life, but it's always time to drop few words :/