Ng-model with objects

Hello,

the code below presupposes that the car object must exist because of the access to the name of the car object. But I don’t want to create an empty car object only for this purpose.
Is there another solution?


  <ion-item>
    <ion-select [(ngModel)]="car.name" placeholder="no selection">
      <ion-option *ngFor="let c of cars">{{c.name}}</ion-option>
    </ion-select>
  </ion-item>

U can control them in ts. Generate new List and fill it with them which have name

this.filteredCars  = [];

this.Cars.forEach(item => {

     if(item['name'] != ''){ 
          this.filteredCars.push(item);
      }

});
<ion-item>
    <ion-select [(ngModel)]="car.name" placeholder="no selection">
      <ion-option *ngFor="let c of filteredCars">{{c.name}}</ion-option>
    </ion-select>
  </ion-item>

1 Like

My problem is anyway that the car object doesn’t exist when opening the page.
The car object will be loaded by a button from database.

Hi

You can use a *ngIf in <ion-item>. ngModel will try to bind to something which won’t be present and that may throw an error.

Something like <ion-item *ngIf="car.name">

But possibly not the prettiest pattern to use. Maybe instantiate with emtpy car is better

Regards

Tom

I firmly believe initializing with an empty car is the best solution. Templates should not have to defend against uninitialized object and array properties; that is the controller’s responsibility. Always initialize every array and object property to at least [] and {} immediately at the point of definition.

2 Likes

I agree it’s not super pretty, but *ngIf can be very useful, I use it in my app. And to answer @rapropos, an empty variable can be done both on provider, page, or service level. The question here is mainly to learn to start.

I don’t understand the difference between provider and service level, but the crucial issue here concerns properties that are accessed by templates. I program in terms of contracts, and the general contract between a template and its controller contains the provision “the controller must keep all public properties in at least a minimally accessible state at all times”. This frees up the template from having to know or care about which properties are assigned to when, which in turn frees up the controller to be able to change that whenever desired without having to worry about breaking the template. Neither *ngIf or the Elvis operator should need to be deployed in the template just to avoid “property access of undefined” errors.

1 Like

It is good to code with the future in mind, and decoupling resposibilities as @rapropos is saying is the ultimate way. But then again, everybody is entitled to his/her own learning curve :slight_smile:

At least I am learning on a daily basis from the stuff I coded in the past.

Thank you @rapropos, I understand it if you take the time to explain your code design pattern. So, you tweak the MVC pattern with quite strong limits between M, V and C. Nice it’s cool :slight_smile: So for you *Ngif is bad? Or a sign of badly designed code in Angular? (I know my code is far from best in Angular)

Only when it’s used to defend against undefined properties in the controller. There are lots of valid uses for it, such as conditionally displayed error messages when a form field is invalid, an accordion component, or this sort of design for rendering a domain language.

Ok @rapropos not to mention i’m not an expert on angular purely, but i’m a pro on the front end. And you helped me tons thank you :slight_smile:

@rapropos the issue with all that, is a ionic app has no default message for that. i guess that’s why people learn and other expect teams to do that for them.