Modify the entity model file generator to not define all entity fields as optional

[gAllegr]

Overview of the feature request

Right now when generating entities on the frontend Angular project, all fields are marked as optional, even if a fields has been specified as required. The idea is to modify the model file entity-name.model.ts to reflect the content of the JDL modeling.

Taking as example the 21-points projects, specifically the Points entity, the JDL section is the following:

entity Points {
  date LocalDate required,
  exercise Integer,
  meals Integer,
  alcohol Integer,
  notes String maxlength(140)
}

but the points.model.ts is the following:

import { Moment } from 'moment';
import { IUser } from 'app/core/user/user.model';

export interface IPoints {
  id?: number;
  date?: Moment;
  exercise?: number;
  meals?: number;
  alcohol?: number;
  notes?: string;
  user?: IUser;
}

export class Points implements IPoints {
  constructor(
    public id?: number,
    public date?: Moment,
    public exercise?: number,
    public meals?: number,
    public alcohol?: number,
    public notes?: string,
    public user?: IUser
  ) {}
}

The project I take the code from is generated with the 6.10.5 version, that's why there is still Moment and not dayjs

The date field should not have the optional character (?) because when the point exists it will surely have the date value. That obviously would lead to a situation like the following:

import { Moment } from 'moment';
import { IUser } from 'app/core/user/user.model';

export interface IPoints {
  id?: number;
  date: Moment;
  exercise?: number;
  meals?: number;
  alcohol?: number;
  notes?: string;
  user?: IUser;
}

export class Points implements IPoints {
  constructor(
    public date: Moment,
    public id?: number,
    public exercise?: number,
    public meals?: number,
    public alcohol?: number,
    public notes?: string,
    public user?: IUser
  ) {}
}

I was also wondering why needing a class for the entity. The constructor is used only in two places, the resolver and the update component and could be replaced by an undefined value.

Entity resolver (taking Points as reference)

@Injectable({ providedIn: 'root' })
// replace Resolve<IPoints> with Resolve<IPoints | undefined>
export class PointsResolve implements Resolve<IPoints | undefined> {
  constructor(private service: PointsService, private router: Router) {}

  // replace Observable<IPoints> with Observable<IPoints | undefined>
  resolve(route: ActivatedRouteSnapshot): Observable<IPoints | undefined> | Observable<never> {
    const id = route.params['id'];
    if (id) {
      return this.service.find(id).pipe(
        flatMap((points: HttpResponse<Points>) => {
          if (points.body) {
            return of(points.body);
          } else {
            this.router.navigate(['404']);
            return EMPTY;
          }
        })
      );
    }
    return of(undefined);    // instead of new Points()
  }
}

EntityUpdateComponent (taking Points as reference)

  ngOnInit(): void {
    this.activatedRoute.data.subscribe(({ points }) => {
      // replace this.updateForm(points); with the following
      if (points) {
        this.updateForm(points);
      }
    });
  }

The constructor is also used into the spec file of EntityUpdateComponent, but just for create a return value, it could be replaced with:

it('Should call create service on save for new entity', fakeAsync(() => {
  // GIVEN
  // instead of const entity = new Points();
  const entity = { date: moment() };
  spyOn(service, 'create').and.returnValue(of(new HttpResponse({ body: entity })));
  // other test code
}

Similarly in the EntityService spec file for the 'should create a Points' test.

Motivation for or Use Case

Should be clear what fields surely are valorized and which not when an entity object is being used. Any developer seeing the model can easily get confused.

Related issues or PR

• Checking this box is mandatory (this is just to show you read everything)

[github-actions]

This issue is stale because it has been open 30 days with no activity.
Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted.
We are accepting PRs 😃.
Comment or this will be closed in 7 days

[deepu105]

Would you like to contribute a PR to improve this? I think originally I amrked all fields as options due to some TS issue few years ago may be it doesnt exist anymore and this can be updated

[mshima]

Not sure this still applies. Moment was replaced with Dayjs.

[github-actions]

This issue is stale because it has been open 30 days with no activity.
Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted.
We are accepting PRs 😃.
Comment or this will be closed in 7 days

[DanielFran]

@gAllegr Can you confirm if this still apply (we switched to dayjs) and you are available to contribute a PR to improve this?