*ngFor needs to pruduce 1 btn for each different object, except when object has same value

I’m creating an app that will list of classes for a teacher on a chosen day, each class being a button on the screen. This list is made using *ngFor and pulls data from a ts file, that originally came from a PHP/database query.

The button would then be pressed by the teacher to show which students should be in class that day. It is an attendance/absence monitoring app.

However, I am testing the *ngFor to make my list, and because the data is stored as 3 objects, each with info for a student, three buttons are being created dynamically by the *ngFor - when in fact, as the three students are in the same class, I need just one button.

The next button would only need to be created for the teacher’s next class that day.

This is an algorithm problem I guess, or possibly there is a different query to be made to get the data from SQL. I don’t know.

I am lost.

HTML FILE 

<ion-list>
    <ion-card padding *ngFor="let cour of planning; let i = index" (click)="showStudents($event, i)">
      <h2>{{ cour.cours }}</h2>
      <p>{{ cour.time }}</p>
      <p>{{ cour.date }}</p>
      <p>{{ cour.lieux }}</p>
      <p>{{ cour.duration }}</p>
    </ion-card>
  </ion-list>

SERVICE.TS

getCoursList(date, idIntervenant) {
return this.http.post('http://localhost/Attendance App/myApp/src/app/api/getCours.php?id='+idIntervenant, {
  date,
}).subscribe(data => {
  console.log(Object.values(data));
  let planningData = Object.values(data);
  const grabArray = planningData[0];
  const id = grabArray.intervenant;
  if (id !== undefined) {
    // console.log('test array', id);
    let navExtras: NavigationExtras = { 
      state: {
        planning: planningData
      }
    }
    this.router.navigate(['/cours/', id], navExtras);
  };
},
  error => {
    console.log(error);
  });

}

PHP QUERY TO DATABASE 

if (isset($_POST["date"])) {

// $id = $_POST["id"];
$origDate = date("Y-m-d", strtotime($_POST['date']));
$date = $origDate;
$id = $_GET['id'];

$stmt = $conn->prepare("SELECT * FROM planning WHERE intervenant = :id AND date = :date");
$stmt->execute([':id' => $id, ':date' => $date]);

if ($stmt->rowCount() > 0) {
    $output = array();
    $output = $stmt->fetchAll();
    echo json_encode($output);
} else {
    $errors = "No data found for this date";
    echo json_encode($errors);
}
// $conn->close();

}

DATA RECEIVED FROM PHP QUERY - 1 ARRAY CONTAINING 3 OBJECTS

[object Array]: [Object, Object, Object]

0: Object cours: “Suivi individuel” date: “2019-07-06” duration: “1h30” etudiant: “james ross” id_planning: 19 intervenant: “2” lieux: “Nice 2” time: “12:00”

proto : Object

1: Object cours: “Suivi individuel” date: “2019-07-06” duration: “1h30” etudiant: “Tupac Shakur” id_planning: 20 intervenant: “2” lieux: “Nice 2” time: “12:00”

proto : Object

2: Object cours: “Suivi individuel” date: “2019-07-06” duration: “1h30” etudiant: “Joyner lucas” id_planning: 21 intervenant: “2” lieux: “Nice 2” time: “12:00”

proto : Object length: “3”

The three students above are all going to the same class, at the same time etc, so I want only one button to be produced dynamically.

If the teacher had a second lesson that day, it would produce a second button, and so on.

At present there are no error messages, I am just not getting the desired result.

Given only what you’ve written here, the primary issue I see is with the database design. The planning table seems to be at enrollment granularity, although it contains information unrelated to enrollment (such as course duration and name). I would redesign the database structure so that there is a table with one record per course, another with one record per student, and then use foreign keys to link both of those to the “enrollment” table that currently seems to exist. That way you can select out of the course table here and your problem should melt away.

If rearchitecting the database isn’t feasible, you can loop through on the JavaScript side making a separate array containing an entry for each course (although since all I see are course names, that becomes somewhat fragile).

Yes, I think the restructuring of the databases is the way to go. Thank you.