Angular2 sometimes bootstraps before meteor account information is ready. about angular2-meteor-auto-bootstrap

[barbatus]

I don't get the point here. Meter.user() is a reactive method, so why not to wrap it in the Meteor.autorun in that component's constructor and redirect when it's not null?

[vangorra]

While Meteor.startup() does a good job telling us when the platform is ready to be worked with, the meteor client lifecycle is more involved. After Meteor.startup(), resolution of account status and user session is established. The current implementation opens the app to a senario when Angular2 bootstraps before the user session information is established. While you can use autorun to populate the user, it adds a lot of code to a component specifically to deal with the fact that meteor isn't entirely ready to be worked with. I've added a couple examples that demonstrate the difference.

Waiting for bootstrap to resolve the user session:

@Component({
  template: `<div>Here are your posts...</div>`
})
export default class MyPosts implements OnInit {
  private user : Meteor.User;

  ngOnInit() {
    this.user = Meteor.user();
    if (!this.user) {
      this.route.navigate(['LOGIN']);
    }
  }
}

This approach has it's advantages:

• Pure angular2 syntax. Super easy for a dev familiar with angular2 to work in this manner.
• Redirect occurs early in the component lifecycle and before the template is rendered.

Implementing our own user resolution in the component:

@Component({
  template: `<div *ngif="user">Here are your posts...</div>`
})
export default class MyPosts implements OnInit {
  private user : Meteor.User;
  constructor(private ngZone : NgZone) {}

  ngOnInit() {
    let self = this;
    Meteor.autorun(() => {
      self.ngZone.run(() => {
        this.user = Meteor.user();
        if (!this.user) {
          this.route.navigate(['LOGIN']);
        }        
      });
    });
  }
}

There are a few drawbacks here:

• Use of NgZone to get the user to the template adds a lot of boiler plate. This is not a well-known library especially to newer angular2 devs.
• The redirect occurs after the template is rendered and presented to the user.
• To keep the template from being shown to the user, we have to prevent rendering with *ngIf.
• ngOnInit becomes place to start an init process specific to meteor. After the meteor specific init is done, then the component is truly initialized. This pollutes the angular2 component lifecycle.

Ultimately, it asks an awful lot of a developer to understand the nuances of the meteor lifecycle and to account for that in their component. While at the same time, rendering the angular2 lifecycle as it relates to meteor, not so useful.
The meteor angular2 bootstrap does a great job making the integration between the frameworks seamless. Let's take away another seam and make it reven easier for an angular2 dev to use meteor.

[barbatus]

To avoid injecting ngZone you can extend MeteorComponent and use its this.autorun like
this.autorun(()=>{...}, true).
I see the bootstrap of this package as an equivalent of Meteor.autorun, which doesn't touch authentication at all; it should do the basics for now and that's it.
Otherwise, Angular2 has bunch of ways to avoid weary of repeating a code like you mentioned in the components. For example, you may try to create a decorator that inject reactively Meteor's user to a component, i.e., like https://github.com/Urigo/angular2-meteor-accounts-ui/blob/master/modules/annotations.ts#L10. Or you may try to create an asynchronous version of CanActivate decorator similar to https://github.com/Urigo/angular2-meteor-accounts-ui/blob/master/modules/annotations.ts#L42, which returns a promise and marks it resolved when the user data has arrived. BTW, this accounts package is slowly being developed, so I believe one day it'll have everything needed to do Meteor auth in the angular2 way.