Auth docs don't demonstrate where to get AuthProviders, AuthMethods

[Splaktar]

On first reading the Auth docs while doing the RC.4 to 2.1.0 upgrade and coming from angularfire2 beta.2 to beta.5, it was confusing if there was some new way to getting AuthProviders and AuthMethods. I was wondering if these come from the AngularFireModule now or if they came from a service or something. It would have saved me a lot of confusion to just specify that that they are still imported from angularfire2 like before. I.e. import { AngularFireModule, AuthProviders, AuthMethods } from 'angularfire2';

https://github.com/angular/angularfire2/blob/master/docs/5-user-authentication.md

Currently:

const myFirebaseConfig = {
  apiKey: '<your-key>',
  authDomain: '<your-project-authdomain>',
  databaseURL: '<your-database-URL>',
  storageBucket: '<your-storage-bucket>',
}

const myFirebaseAuthConfig = {
  provider: AuthProviders.Google,
  method: AuthMethods.Redirect
}

@NgModule({
  imports: [
    BrowserModule,
    AngularFireModule.initializeApp(myFirebaseConfig, myFirebaseAuthConfig)
  ],
  declarations: [ MyComponent ],
  boostrap: [ MyComponent ]
})
export class MyAppModule {}

It would be less confusing as:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { AppComponent } from './app.component';
import { AngularFireModule, AuthProviders, AuthMethods } from 'angularfire2';

const myFirebaseConfig = {
  apiKey: '<your-key>',
  authDomain: '<your-project-authdomain>',
  databaseURL: '<your-database-URL>',
  storageBucket: '<your-storage-bucket>',
}

const myFirebaseAuthConfig = {
  provider: AuthProviders.Google,
  method: AuthMethods.Redirect
}

@NgModule({
  imports: [
    BrowserModule,
    AngularFireModule.initializeApp(myFirebaseConfig, myFirebaseAuthConfig)
  ],
  declarations: [ AppComponent ],
  bootstrap: [ AppComponent ]
})
export class AppModule {}

The other doc examples use AppModule and AppComponent instead of MyComponent and MyAppModule as well.

[katowulf]

Great stuff! Thanks for the contribution. Please use the issue template in the future, it's required and not optional.

[Splaktar]

@katowulf I did use the issue template, but none of it applied to a docs only change.

[katowulf]

Thanks, it may not feel immediately intuitive, but having the content you put here in the categories we asked for helps us to quickly parse and prioritize the the many issues. I'd imagine this fits nicely into the expected behavior and actual behavior. And having the version info at the top lets us know that you're on the latest right away, so we know everything here is legit and applicable. A lot of docs PRs can be misunderstandings about version compatibility or due to coding changes, so it is helpful here. Of course, all of this is a bit nitpicky; just keep it in mind for the future. It helps us reduce maintenance workload and focus on the functionality. ♡

[Splaktar]

I fully understand the need for and benefits of issue templates and the challenges of maintaining an open source project. But thank you for at least trying to be diplomatic about this, even if it's not really what I want to hear.

Please accept my feedback that the issue template needs to be improved to better accommodate doc issues which do not require to have any version of the library installed. In fact, I'll open an issue for that so that it can be discussed before a PR is submitted.