*ngFor not work with Ionic 3

Simple as follows.

I have a *ngFor=“let part of parts”

Parts is filled trough Firebase
As follows:


But the ngFor not update the list, only if I do back an then again open the view.

You need to pass the value trough the async pipe while your value are getting asynchronously.

Here is an example:

// in the service
    return Observable.interval(2200).map(i=> [{name: 'car 1'},{name: 'car 2'}])

// in the controller
vehicles: Observable<Array<any>>
ngOnInit() {
    this.vehicles = this._vehicleService.getVehicles();

// in template
<div *ngFor='let vehicle of vehicles | async'>
1 Like

That’s a good One,
Do you know how to await for a forEach to fill this.data var and then observer.next(this.data)?
The forEach is for sub querying Firebase node realtime. With for each result of parts in vehicle/parts/{id}
get parts/{id}/info

My code looks like this:
Please Help.
Can you advice me or fix my code?

*ngFor = “let part of parts | async”

This.parts = new Observer(

this.hola(snapshot).then(result =>() {


async hola(snap) {

await snap.forEach((item) => {




getData()  {
  return new Observable((observer) => {

          this.addToArray(snap).then(result => {

            setTimeout(function() {



            }, 500)





   async addToArray(snap) {

    var data = [];

      var a = await this.snapshotToArray(snap)

      for (let part of a) {
        await this.db.database.ref(`/users/${part.key}/contact`).on("value", async snapshot => {

          await data.push(snapshot.val())


    return data;


Never use the word function

Use fat arrow

Irrespective if that solves your issue, it will prevent many others

In addition to “function”, two other words that should be avoided at virtually all costs in a typical Ionic application are “new” and “setTimeout”.

How do you avoid using new ? I understand for the other point but not this one

Use operator to transform the promise into observable if u use firebase sdk

Or not transform at all to observable and resolve into array

Less lines means less bugs

1 Like

Interesting, thanks for the link !

One rough way of classifying objects in a typical Ionic app would be:

A. interfaces (most model layer things go here)
B. components and services
C. futures (Observables and Promises)

A can be reanimated from JSON or assigned as object literals: let foo = {bar: 'baz'}, so no need to new them.

B are managed by Angular’s DI, so you just inject them in constructors and let DI manage their lifecycle, so no newing here either.

C are the ones people are initially most tempted to new, but 99% of the time you are starting with a future generated by an outside source (such as HttpClient or an ionic-native plugin), and it is a design antipattern to multiply them needlessly when transformation via an operator can be done instead.

EDIT: thanks to @izio38 for pointing out a case for C that is more common than I had thought of: initializing Subjects in service providers.

Why would you not use the new keyword in Typescript?
There’s nothing wrong to use it while we do it properly.

As I just wrote, because there is almost always a better way to do whatever is needed, and I have seen hundreds of threads on these forums where new was the cause of bugs.

Any use of new that I would consider “proper” in an Ionic app would be in shim code designed to interface with external entities that are not Angular-aware; not in the application code itself. I can’t think of a single exception to that, so I guess maybe we disagree on what is “proper” in this context.

Yeah we disagreed cause Interface and classes are made to work together. Interfaces are for Type checking, readonly, indexes etc… while classes are “object”. I know Js isn’t a OOP langage, but in reality, it just convert the class into a function with sub key for each method and props.

Even Angular team use new keyword in their *ngIf directive declaration

1 Like

You’re right: that’s a case where I agree new makes sense: when initializing a Subject (generally in a service provider).

1 Like