Open trsh opened 6 years ago
+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.
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.
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
I have two points to criticize.
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 ...
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.
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!
I do not get the conclusion of this discussion :(
@dschnelldavis with all respect, I do not know what going an in your life, but it's always time to drop few words :/
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?